Design team “skill share” sessions


Just a snippet from the beginnings of our skills/tools spreadsheet

No matter the workplace, we all get lost in the design and product doldrums sometimes. There are times when everyone is so heads-down in their work bubble of production, spec’ing, etc. that we forget we’re even working on a team.

For this reason, design teams often hold regular meetings to come back up for air and set aside time to talk about ideas, inspirations and other what’s-on-my-mind and “professional development” topics.

Rather than listening to presentations or watching yet another TED talk, I wanted something more pragmatic and no-nonsense. The result was the skill share session, which runs as follows:

  1. The facilitator (that’s you!) puts together a list of 20-30 popular design and development tools – some that are more well-known and others that are new or even yet-to-be-released.
  2. Participants are asked to review the list, marking each skill as “Would learn” and “Would teach”, and are encouraged to add missing skills or tools to the bottom of the list.
  3. Prior to the session, the facilitator puts together a “suggested” list of pairs based on matches in teaching and learning designations – these pairs aren’t set in stone, but it helps to get the session started off quickly.
  4. At the session, pairs are formed and the meeting time is split into a “you teach me” / “I teach you” format, where each person gets to teach a skill and then learn a skill with their partner.

So far, the meetings have been very successful, with attendees seeming eager to participate and get the opportunity to both flex some muscle and learn a new skill in a short timeline. Learnings thus far:

Alleviating stage fright
I’ve been using a public spreadsheet where everyone has read/write access – it’s easy to do, but also ensures that the team can see the recent additions from teammates without some sort of approval process. Since all team members can view the spreadsheet, it’s possible that some team members may become self conscious about their visible lack of skills, or they may feel tempted to misreport skills to alleviate such concern. This is why I’ve labelled columns as “would teach” and “would learn” rather than something such as “has this skill”. Further, I’ve made it a point to encourage attendees to label skills that they would be most enthusiastic about teaching, and to not mark skills that they have little interest in teaching – because the skill is rusty, perceived to be of little future value, or any other reason. Alternatively, other team members responses could be made private – this would require an intermediary system for managing ratings and additions – something I frankly haven’t had time to explore, but I suspect it would be worthwhile to try, especially for larger teams where relationships aren’t as tight. For our team, I think the current system works well, and – to be completely honest – I suspect that participants actually appreciate seeing the larger list and generally knowing what skills are “hot” for the team collectively. An aforementioned “intermediary system” might still expose the “hotness” of skills without revealing individual preferences, perhaps. Food for thought.

Keeping the list simple and accessible
Since the list can be added to at any time, and because new design tools are popping up seemingly overnight, it’s important to revisit the list and encourage participants to update their preferences prior to any skillshare meeting. Categorization of skills/tools might seem valuable, but I’ve found that, because the list can change rapidly and be added to, categories are mostly ignored or only add noise to the list. Would you categorize Macaw as a “development tool”, “prototyping tool”, or “responsive design”? For the purpose of the skillshare meeting, who cares?

Being realistic about what a “session” entails
Depending on the time you can devote, it can be difficult for participants to learn and teach anything meaningful in a short span of time. If Fred really wants to learn Objective-C, should you even bother with a 30-minute time limit? For this reason, I’ve emphasized that our one-hour sessions focus on introducing partners to the topic and, if it’s a more ambitious topic, to focus on introductory resources and ideally acting as a future mentor or go-to person when the partner is pursuing the topic outside of the session.

I’m hoping to run another skill share session this week, so I’ll continue to riff on the format. If you end up exploring a similar process on your team, I’d love to hear about it!

Leave a Reply

Your email address will not be published. Required fields are marked *