You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Thursday, Jan 12, 2006, 8:50 AM in The Spout
PM Skill #4: Exhibiting the Behavior You Want
At our last team milestone, we had stepped up the pace in the last two weeks to make sure that we were done in time for a demo by one of our internal stakeholders (demoing your stuff is a wonderful way to communicate, but having other folks build on your stuff to demo their stuff is even better [so long as they remember to mention your stuff]). When we decided to step up the pace, I let everyone on the team know that I was available 24/7 until the demo, providing all my contact numbers. I was actively working on a chunk of the implementation, so I would send out status and check-in mails whenever I had completed something, often in the middle of the night or early in the morning (I didn't get much sleep for those two weeks). When folks had questions, I was there to answer them, day or night. I was working long and focused hours and I was making good progress against my goals to meet the deadline for the demo.
In other words, while I never once asked the team to double their work efforts, once we'd all agreed to meet the shortened deadline, I stepped up my pace, let them know I'd stepped up my pace and expected them to do the same. This is the same no matter what behavior you want, whether it's working long hours (only temporarily, though, else you'll burn out your team), showing up to meetings on time or getting powered sugar on your keyboard. Some individual members of your team may not change their behavior, but they definitely won't if you're not willing to.
Thursday, Jan 12, 2006, 8:21 AM in The Spout
Survey: The Future of Publishing
Karen Gettman, my editor at Addison-Wesley, called and asked me a bunch of questions about the future of publishing yesterday. After our discussion, she asked if I knew anyone else and I volunteered to put a survey up on my web site.
To answer this survey, send the questions below and your answers to Karen.Gettman@AWL.com. Also, include your phone number so Karen can call to follow up (she finds the phone conversations to be most illuminating when it comes to really figuring out how people want to get to info -- we spent a bunch of time talking about hardware and software for ebooks). Thanks from Karen for your help!
- How do you learn about things to keep current in your job?
- What questions have you recently had and how did you search for the answers?
- How do #1 and #2 work well and poorly today?
- How would you like your information "served up?"
- What part of content (besides the content itself) do you value the most (name of its creator, form factor, etc.)?
Wednesday, Jan 11, 2006, 10:32 AM in The Spout
PM Skill #3: Getting Things Done
Fundamentally, a PM's job is to get things done. If you're going to plan and ship while keeping your team happy, you've got to plan, ship and keep your team happy. All of this pre-supposes you can get things done.
Getting things done isn't magic. For example, I'm sure everyone reading these words can get something done all on their own. However, when you're a PM, you've got to lead a team to get something done and that's a little trickier. Here's what I do:
- Identify a problem, e.g. I don't like doing Sudoku with pencil & paper.
- Identify a solution, e.g. put Sudoku into Windows.
- Identify your customers, e.g. Sudoku freaks that would prefer a better experience than pencil & paper.
- Figure out the folks that care one way or the other, e.g. the people that decide what goes into Windows and pitch your solution, either convincing them it should be done or convincing yourself it shouldn't. In most cases, your solution will need to change a bit to match your agenda to theirs.
- If you still think it's a good idea, find the folks that need to approve of the work (it may be the same folks that decide) and negotiate what success looks like, e.g. a user of Windows can choose Sudoku from the Games menu of the next version of Windows and have a happy Sudoku playing experience.
- Find the folks that need to help, e.g. the people that actually puts things into Window, and plan the work, e.g. write Sudoku, debug Sudoku, test Sudoku, get it into the manifest of files that make up the Windows setup, etc.
- By now, you've got a group of people involved with your idea. At Microsoft, these people are called stakeholders, and form the team of folks getting things done, whether it's approving the work, enabling the work, doing the work or using the work. With these stakeholders, you need to schedule the work. Scheduling accurately is a whole other topic, but to get things moving, you basically need an owner for each and every task in your plan and you need that owner to commit to a date, e.g. you (the PM) bill spec Sudoku by 1/1/06, Bob will write Sudoku by 2/1/06, Pete will test it as Bob writes it, etc. Also, if the work is more than a month or so, break it into milestones so that people see steady progress.
- If these people aren't enough to get the job done in a reasonable time frame (as determined by your schedule), you'll need to get additional resources, either by hiring or convincing other people that already work with you to spend their precious time working on your idea.
- Now that you've got a set of tasks and a schedule, you need to execute. That means making sure everyone's got what they need to do their work, including time, tools, the right information, etc. This also means gathering information about how folks are doing and sharing it with the stakeholders (a lot of them, like your boss or his boss, won't be doing the work, but will care about it). Finally, executing as a PM means holding the schedule up in front of the individual faces on your team every once in a while and "motivating" them into living up to their commitments, where "motivation" includes encouragement, bribery, shame, nagging, reminding them what problem you're trying to solve so as to keep them on track, etc.
- When you've met your criteria of success (which will involve more stakeholders, time, tasks and/or resources than you thought), ship it. Do not forget this step! I know it's silly, but unless you've got an ever-decreasing list of tasks that shows you're getting closer to a real ship date instead of further, you've lost one of your major executing motivations. In fact, getting close to a goal is so important for the health of your project and your team, that you should have as much shipping in your schedule as possible, which is why must non-trivial projects are broken down into milestones, each of which you'll share with some set of your stakeholders, e.g. daily builds stay internal while betas are shared with customers.
- After you've shipped, don't forget to post-mortem. In fact, I like to do port-mortems after each milestone. This allows you to decide what went well and poorly so you know what to repeat and what to avoid in the future. In addition to increasing your team's knowledge so that you can do better next time (or at least not do any worse), the post-mortem is a great time to really highlight the team's accomplishments, making sure to point out the work that individuals did. People need to know that their work is appreciated. That's not to say you need to plunk down a chunk of Lucite on their desk, but a simple "thank you" with specifics in front of a crowd goes a long way.
As an example, after the 2005 PDC, I wanted to make sure that Avalon and Indigo worked very well together. Obviously, that's not something I can do myself (I have check-in rights to neither team's source code). I'm not done with this work yet, but here's how it's coming along:
- Problem: Avalon and Indigo didn't work together during my PDC talk as I would've liked.
- Solution: Getting a set of Avalon/Indigo technology samples into the SDK (a technology sample is minimalistic, the SDK already has a bunch of Avalon/Indigo application samples, which attempt to show something more akin to real-world usage).
- Customers: Developers using Avalon and Indigo together.
- Pitch: I made my pitch to the people in charge of the SDK samples for Avalon and Indigo. They liked the idea and became my first stakeholders. They also reminded me that WinFX included Workflow, which quadrupled the pairings of technologies, i.e. from Avalon/Indigo to Avalon/Indigo, Avalon/WF, Indigo/WF and Avalon/Indigo/WF, and required an extra stakeholder. They also reminded me that I'll want to get someone from the SDK team itself involved, because I'll want to make sure there's a special section in the SDK samples that lists integration samples separately from the individual technology samples.
- Success: A set of samples that show the "right" way to integrate the technologies and meet the standard sample bar of quality, e.g. they compile, they run, they pass FxCop, etc. This definition of success reminds us that the problem isn't that we don't have enough samples, but that the pieces of WinFX don't work together well enough, which is why getting architects from each technology into the room together to decide what's "right" (and changing the technologies appropriately) is the real job. Getting samples into the SDK is just the thing we're doing to motivate this activity.
- Plan: We've got a list of samples that cover integration scenarios, what technology pairing they each cover, who owns ‘em, who's authoring ‘em and milestone dates, e.g. code complete, architectural review, submission, SDK drop release date.
- Schedule: We composed the schedule by looking at the samples we wanted to do, picking the releases of the SDK that we wanted to hit (different releases had different features that we wanted to integrate together) and then backing it up from their, i.e. if we want to hit the Foo CTP, the submission deadline is n, we'll need m weeks to turn around architectural feedback, so we need to be code complete and have the review on n-m, etc.
- Resources: Remember that this project started with just me, but now includes a decision-maker (or two) from Avalon, Indigo, Workflow and the SDK as well as sample authors and point people to get individual tasks done. In addition, there's my boss and the bosses of all of the folks doing the work that have to approve how folks spend their time, all of whom have to be kept informed and can have input to the process. Some folks are part of the team because they were convinced of the importance of the work and some are part of the team because their bosses were convinced and asked them to participate, but none of them work for me. It's common for a PM to run a project composed entirely of people that don't work for them, so sharpen up your people skills.
- Execute: We meet semi-weekly to make sure we're still on track and to identify any addition tasks and owners, e.g. adding the new section to the SDK, etc. Also, I'm the author of a bunch of the samples, so I have to meet the deadlines personally. As the PM, if I don't meet my own deadlines, I've got no leg to stand on when I ask others to meet theirs.
- Ship: We're coming up on the first code complete deadline, which was delayed a bit because we needed a stable internal build of a WinFX CTP that we're targeting to have the first set of samples placed into. Once we get the first set running on the right CTP, we'll review, fix problems in the samples, file architectural issues we discover in the review process as bugs against the individual technologies, submit the samples to the SDK team for their quality check and out it goes!
- Post-Mortem: We haven't done this yet, but I things I expect to see come out of it is how to keep this work going. There are lots of combinations of technologies that we promote at Microsoft and there needs to be a way to make sure that they work well together, which, after all, was the whole point of this exercise.
Tuesday, Jan 10, 2006, 4:55 PM in The Spout
A Mac that runs Windows?!?!?!?
Holy shit! I Macintosh that runs Windows!!!
"After Jobs' presentation, Apple Senior Vice President Phil Schiller addressed the issue of running Windows on Macs, saying there are no plans to sell or support Windows on an Intel-based Mac. 'That doesn't preclude someone from running it on a Mac. They probably will,' he said. 'We won't do anything to preclude that.'"
I can't tell you how long I've waited for a laptop built by Apple running Windows built by Microsoft.
Thursday, Jan 5, 2006, 9:51 AM in The Spout
I'm really digging live.com
I've tried all the portal sites at one time or another (yahoo, google, etc), but none of them have ever stuck 'til now. Since I gave up on subscribing to blogs, I find myself surfing to two sites every day: slashdot.org and live.com. I like getting the news headlines and I really like the gadgets (not one, but *two* versions of Wahoo! [both of which end in "tris" for some reason...]).
It's not perfect (the menu on the left obscures some text, there's no auto scrolling while you drag and it doesn't seem to like my smart phone), but it's definitely "sticky," at least for me.
Thursday, Jan 5, 2006, 9:27 AM in The Spout
Mobile Movie Listing Sites Compared
On a recent mailing list discussion, folks posted a large number of URLs for mobile movie listing sites. Since searching for movies is one of the things I like to do on my smart phone, I did a quick compare and contrast, looking for the site that would give me a quick list of movies by my house. Here's what I found:
Yahoo Mobile: once I chose my location, it showed me theaters, not movies in my location. I don't pick the movie I want to see by theater, I pick it by title and time.
Google Mobile Search (XHTML): required me to enter "movies <zip>", but once I did, showed me a nice list of movies (in random order) along with running times and a rating (although I have no idea where the ratings come from), the genre and the maturity rating. Clicking on a movie showed me a list of times by theater, an address and a phone number. Once I save the URL into my smart phone favorites, this site could be handy...
Fandango Mobile: crashed when I entered my zip code.
Hollywood Mobile: asked for a zip code, then showed me a list of movies. Clicking on a movie didn't show the theater closest to my house, so that dropped it from my list of potentials.
Metracritic Mobile: shows movie reviews, but doesn't allow me to enter a zip code to show movies near my house.
Moviefone Mobile: can find movies by movie or theater in a cute tabbed interface. However, instead of showing me all the movies, it made me pick by category. Once I picked a category and a movie, it showed the local theaters and times.
IMDB Showtimes & Tickets: until this review, I’ve been using IMDB for my movie times. It's designed for a desktop browser (they don't have a mobile version I know about), but for a given zip code, you get all the movies, the IMDB rating, the maturity rating and the local theaters. You can also choose to look at the results by theater and easily change the day (e.g. tomorrow's movies) or sort by theater. There's a lot of scrolling around on a phone, but before this review, it was the one I used.
Of all of the sites, IMDB has the most capability, but it's awkward on the phone. I think I'm going to see how the Google mobile movie search stands up to regular use.
Thursday, Dec 29, 2005, 11:34 PM in The Spout
Dirty Publishing Secret: Indexes Suck
I hate to say it, but indexes are the one place where I skimp when writing a book. I go round and round on sentence structure, figures, story, flow, coverages, what to cover, what to leave out, section headings and all of the other minutia that goes with writing a book, but I never bother with the index.
The index is one of those things where, as an author, you can write the index yourself, complete with page numbers (added manually) or your can let the publisher outsource it (although be careful when signing the contract -- some publishers will charge the author the outsourcing fee!). So, for no work, I can get something that's OK, but generates some complaints (maybe 1 out of 20 is about the index) and let Safari, Amazon and Google be the full-text search equivalent (even good indexes suck compared to that) or I can do a *ton* of work to reduce the number of complaints to 1 out of 30 (this is just a guess but it nicely justifies not doing the work, don't you think? : ). As it turns out, the publisher will let you proof an index, but I have yet to figure out how to do that.
Anyway, that's why most indexes suck. Sorry. I think you should read my books cover-to-cover, memorizing as you go, eliminating the need for an index anyway. : )
Wednesday, Dec 28, 2005, 11:04 AM in The Spout
PM Skill #2: Building Consensus
I know the phrase "building consensus" is a touchy, feelie term, but it's the best description of one of the most important skills a PM can have. As a PM, you've often got responsibility but no authority, which means you have to spend time convincing everyone that the work you need done is in their best interests to do. Getting a whole group of people pointed in the right direction is the "consensus" part. The "building" part is how you get there.
One way to build consensus is to hole up in your office for days on end, drafting a plan down to the task and sub-task level, emerging only when you've got everything just right, presenting it to the team in one, fell swoop. I'll call this the "engineering way" of building consensus, because it seems to be the first reflex of software engineers new to the PM world. Unfortunately, this way almost never works. The first problem with this technique is obvious: there ain't no way your plan is going to survive contact with your team. They'll question the highest level assumptions that affect the next level, which affect the next level and so on. Even if, eventually, your plan was 100% the right one, you can't just jump to the end game w/o bringing your team along with you. The second, less obvious, problem with this technique is that, while you're holed up in your office, the rest of the team will have splintered into factions, going in their own directions and building their own ideas of what the team should be doing which you now have to steer them away from.
My preferred technique for building consensus is what I'll call "the big mess." The idea is you get the team (or a representative sample of the team) into a room and you ask the leading questions, e.g. What are we trying to accomplish? How do we get there? Who does what? How does that fit into the bigger picture? How do we involve folks outside the team? I call this technique "the big mess," because that's how it starts and it only gets better through discussion and debate, led by the PM. One nice thing is that it's usually a lot faster than holing yourself in an office, because you don't have to make all of the planning decisions yourself (sometimes you don't make *any* planning decisions), although you better be a fast hand at keeping track of the team consensus as it builds and playing it back periodically to make sure everyone's staying in sync (Oliver Sharp turned me onto MindJet's MindManager software for this task). One downside of this technique is that it keeps the decision makers on the team from doing anything else while you're hashing through the mess, but the upside of this is that they're not off pushing into a bunch of different directions.
As a tweak to "the big mess" to make it a bit less messy, I like to have a small proposal to seed the process. It's always easier to start a discussion with folks telling you what they don't like about an existing set of ideas then to start with a blank sheet of paper. If this "seed" comes from my mind alone, I stop myself from holing up in my office for days by giving myself only the hour before a mess meeting to prepare such a seed. I can mitigate some of the mess with a seed that I'm willing to dig up, but I actually make things harder if I show up with a fully formed tree that needs chopping down before the team is happy (see "the engineering way" of building consensus above).
If I want to show up at a mess meeting with a seedling, I can spend more time nurturing my budding consensus with a bunch of pre-meeting 1:1 meetings with the decision makers on the team to get their take. This only works if I'm able to come up with something that takes the majority of folks' concerns and ideas into account and if I circle back with folks on refinements to the things we discussed before in the pre-meeting meeting. In this way, things are still a mess, but it's the PM that deals with a large part of it up front.
Ideally, if you have a pre-mess mess (my name for the collection of pre-mess-meeting meetings), you can show up at the mess meeting to merely tweak and ratify, but this is a rare thing indeed. If I were you, I'd be prepared for the mess and use pre-mess discussions as a way to inform how you lead the discussion.
Friday, Dec 23, 2005, 10:34 AM in The Spout
PM Skill #1: Communicate, Communicate, Communicate
I think the title says it all: if you're a PM, you've got to communicate. That includes to your team, your management, your partners and your customers. As I mentioned, I'm a big fan of getting people's raw feedback with informal chats. I also like to schedule regular 1:1s with as much of the team as I can.
For folks not on the immediate team, I like to give them updates at the ends of milestones in the form of a PowerPoint presentation. The outline often looks like this:
- Milestone Goals
- What we did
- What we learned
- What's next (goals and activities for the next milestone)
This lets folks give feedback on several levels, i.e. did we pick the right goals, did we do the right things, how do we apply what we learned, what should we do next, etc. It also gives them lots of places to tell them how their own work and requirements fits in with ours so that we can make sure we stay in sync.
For these kinds of presentations, you know you're not having them regularly enough if management has to ask for one or if you can't put one together in a day or two. You want folks to see you communicate proactively, not reactively.
For folks on the team, I like to send around weekly (or near weekly) status emails:
Goals
- goal 1 (100% done)
- goal 2 (50% done)
- etc.
Summary
In the last week, we ...Plans
In the next week, we'll ...Tasks (from the bug database)
csells 452 12/13 Post PM Skill #1: Communication
...
I also like to post each status mail internally so that folks can skip a particular status or come into the team later and still get caught up quickly (a SharePoint site is excellent for this).
Often it's the case that team members won't read all (or even most) of your status emails. Don't let that stop you from sending them! At the very least, it helps you keep your head around what's going on and what needs doing. Also, it's comforting for team members and management to know that status is available even if they don't read the emails, because it lets them know that someone is watching the details. Plus, when someone asks a question that's answered in the status, I tend to reply with the status email as an attachment, letting them know that someone's all over things.
Thursday, Dec 22, 2005, 12:00 PM in The Spout
PM Skill #0: Know Your Job
I've been a Program Manager (PM) at Microsoft now for about 2.5 years. Before that, I've been a managing contractor, a lead author, an engineering manager and a chief architect (both for commercial and shared source projects). Over a 12 year career, I've not only contributed to lots of shipping projects, but have lead several.
Most recently, I've been applying that experience to being a PM on a real Microsoft product team, which is its own unique experience. I've only been doing it for a few months, during which I spent a lot of time studying internal PM training materials and asking my exemplar PM brethern how they do it. At the same time, I've been helping a colleage get up to speed on just what it means to be a PM, so I thought I'd use this blog for what I think it's best at -- writing down what I believe and having people tell me where I got it wrong. So, consider these posts (like all posts on this site) to start with "in my opinion."
A PM's job is to ship the right thing on time and on budget, while keeping your team happy. There's a lot in this sentence, so let's break it down:
- "ship" -- first and foremost, the job of any PM is to start with a goal, either self-imposed or assigned, and ship an implementation of that goal. If you don't ship, the rest doesn't matter.
- "the right thing" -- unfortunately, shipping ain't enough, you also have to ship the "right" thing by some definition of "right." This is the most ambiguous part of the job, because any one goal can have many, many implementations and even the goal might not be the right one. My personal definition of right includes getting buy in from your team, your management, your partners (internal and external) and your customers (internal and external). You're allowed to do whatever makes all those folks happy (and good lucking finding the intersection : ).
- "on time, on budget" -- this is all about execution. As a PM, it's your job to lead your team through planning, scheduling, resource management and delivery.
- "keeping your team happy" -- this one is hardest for many engineers, because it involves keeping your team happy, focused and productive. There ain't no rule book for this one, although I find a useful technique to be something widely known as "management by walking around." Many folks won't tell you how they really feel in a meeting, but if you can catch 'em on a phone call or in their office, 1:1, they'll give you their real "gut," which is vital to making sure that folks are happy, motivated and on the right track.
I've got more opinions about other vital PM Skills, which I'll post as the spirit moves me, but hopefully at the rate of about 1/day 'til I'm dumped the entire contents of my brain, making room for other things. : )
Sunday, Dec 18, 2005, 11:35 AM in The Spout
How come nobody says "impeach?"
WARNING: This is my political side bubbling over. If you only want fun stuff about my kids or technology, this post ain't for you.
Clinton engaged in an consensual adult act in the west wing and endured the impeachment process.
Bush sics the NSA on us w/o due process, starts a war so he can look tough for his dad and continues to dismiss global warming as a myth. Why aren't we impeaching his ass?
Friday, Dec 16, 2005, 5:51 PM in The Spout
Windows Forms 2.0 Book Samples Posted
Mike did some last minute clean-up and checked in the files, so I've uploaded the code sample for the Windows Forms 2.0 book. Enjoy.
Friday, Dec 16, 2005, 8:52 AM in The Spout
Windows Forms Programming 2005 in C# Submitted!
I packaged off the final chapters, figures and PDF files for submission of the WinForms 2.0 book this morning. Michael made it easy by fixing all the last minute nits I found, producing the PDFs and bundling all of the figure files together (he separated the graphics from the Word docs using a WinForms 2.0 program, of course!).
In spite of the fact that I've been working on long-lead prototype coding for the last month and Mike's been moving to the US from Australia, we managed to get the book submitted a full 15.5 hours early (they meant midnight when they gave us a 12/16 deadline, didn't they?!?).
I'm so excited to get the book in your hands, that I've asked Mike to check in the files he's got checked out so that we can post the code samples ASAP. It'll still be a while before the book is in your hands, though. We took 22 months to write it, but it's the 3 months it takes to print it that always sticks in my craw the most for some reason. : )
Wahoo (2)!
Wednesday, Nov 23, 2005, 7:57 AM in The Spout
A C# 2.0 anon delegate "gotcha"
I'm a huge fan of anonymous delegates, but I ran into a gotcha this morning when using anon delegates inside a for-loop:
class Worker {
public event WorkCompleted Completed;
public void DoWork() {
Console.WriteLine("Worker: work completed");
if( this.Completed != null ) {
foreach( WorkCompleted wc in this.Completed.GetInvocationList() )
wc.BeginInvoke(delegate(IAsyncResult result) {
// Use wc from surrounding context
int grade = wc.EndInvoke(result);
Console.WriteLine("Worker grade= {0}", grade);
},
null);
}
}
}
}
When I run this code, I get the follow exception:
System.InvalidOperationException:
The IAsyncResult object provided does not match
this delegate.
What's happening, of course, is that the wc variable continues to change after the dynamic invocation happens instead of the value being stored away, one for each call to BeginInvoke, as I'd intended. One fix for this problem is to pass the value I wish I could take off the stack as the async state argument:
class Worker {
public event WorkCompleted Completed;
public void DoWork() {
Console.WriteLine("Worker: work completed");
if( this.Completed != null ) {
foreach( WorkCompleted wc in this.Completed.GetInvocationList() ) {
wc.BeginInvoke(delegate(IAsyncResult result) {
// Pull the value out of async state
WorkCompleted wc2 = (WorkCompleted)result.AsyncState;
int grade = wc2.EndInvoke(result);
Console.WriteLine("Worker grade= {0}", grade);
},
wc);
}
}
}
}
This isn't quite the elegant code I'd like to write with anon delegates, however. I can do a little better by creating a variable on the stack specifically for use in the delegate:
class Worker {
public event WorkCompleted Completed;
public void DoWork() {
Console.WriteLine("Worker: work completed");
if( this.Completed != null ) {
foreach( WorkCompleted wc in this.Completed.GetInvocationList() ) {
WorkCompleted wc2 = wc; // Copy wc for use in delegate
wc.BeginInvoke(delegate(IAsyncResult result) {
int grade = wc2.EndInvoke(result);
Console.WriteLine("Worker grade= {0}", grade);
},
null);
}
}
}
}
In this case, each time through the loop, a new variable is created on the stack specifically for that invocation of the loop and is therefore unchanged by the time the anon delegate is executed. This still isn't quite ideal, but it's not too bad.
Tuesday, Nov 15, 2005, 11:05 PM in The Spout
Turning off special features in DVDs and CDs?
Does anyone know if it's possible to turn off the special PC features of DVDs and CDs? I'd like to avoid Sony-sponsored virus enablers on CDs and required players for DVD content and just treat each of these CDs and DVDs as un-special. Is such a thing possible?