PM Skill #9: Team Off-site

I’ve been doing some design work with a small part of my new team for a few months now and we’ve gotten largely on the same page with each other. However, there were 20-some odd folks that we hadn’t done a good job keeping on the same page, so ChrisAn proposed an off-site. I proposed the format:

• 45-minute slots for each “bucket” of design functionality with the owner of the bucket leading the discussion (my boss, Adam, wanted to make sure that at least half of each talk was *not* lecture from the speaker). Each session was followed with a 15-minute break.
• 90-minute break-out sessions where each person had to pick their technology bucket and work with the owner to produce a 2-page functional spec and a 2-page technical spec.

If this format sounds like a tweaked DevCon to you, then you know where I got the format.

We started at 8am (1-2 hours before most folks start their day @ MS), so that gave us a little shared adversity to help build the team.

The 45 minute sessions made sure that the presenter had to get to the meat quickly, while the 15 minute breaks allowed folks some downtime to catch their breaths, check their email and chat with their brethren (this was a new team, so “bonding” time was an important element).

The 90 minute break-outs allowed folks to self-select into the bucket that most interested them, validated that we had the right buckets (any bucket w/ too few people would be cut, whereas any bucket w/ too many people would be split), helped establish the base-line for each bucket’s future (we used the off-site to kick-start the buckets) and gave the team a seemingly impossible task given the amount of time they had (shared impossible task == more team building).

Like your average DevCon, the “DesignCon” worked pretty well. We generated a ton of issues in each bucket that the owner hadn’t yet thought of and gave the entire team a kick-start down the road to shared pov. Also, since we had some folks from other, related teams and from upper management, we made sure we were communicating up and out as well as internally.

Of course, just as no DevCon is perfect, neither was the DesignCon, but if you’re looking for a way to get your team pointed in the same direction, I find the DesCon format a good one.