This past week at Drupalcon DC, I participated in a panel discussion about providing Drupal training organized by Sean Effel of Drupaltherapy.com fame.  While the session was not videotaped, Josh Miller has provided a "bootleg" audio recording on his site as part of this Josh Miller Minute series. Thanks, Josh.

Thanks, Sean, for the invite and the great work in convening a panel representing diverse perspectives.  In this post, I will attempt to summarize the philosophy, goals and specific focus of our training program at Advantage Labs (Minneapolis, MN) as I discussed at the session.

Before outlining our training program specifics, I feel the need to stress a few introductory essentials.  Before you open your presentation software to create slide 1, before you even think of announcing your training session, know the following:

• Your overall training program's goals
• Your audience(s)

Know Your Training Program Goals

There is a phenomenal need for training within the Drupal community.  It can be tempting to just dive in and start teaching away.  I would urge a more measured approach, one that will contribute to a sustainable Drupal environment, whether that environment be geographically local (as is ours) or expansive (like the entire online Drupalsphere).  Have a set of goals for your training efforts in general, beyond the goals for each specific training opportunity.  This will aid in focusing your efforts and increase your ability to measure your success.

Our philosophy at Advantage Labs revolves around the desire to empower the local Drupal community by supporting Drupal developers and users.  In short, we don't want to be making Drupal sites as much as we want to provide the means-- tools, support, training, managed hosting-- for others to be using Drupal effectively (and happily).  The idea is to be an active contributor to a local Drupal ecosystem which can become self-sustaining for all who participate.

Know Your Audience(s)

You know your material, that should be taken for granted.  Equally-- if not not more-- important is how well you know the people you intend to train.  An ill-targeted training can be disastrous-- to your reputation and to the goals you have set for your training program.  Keep track of what is happening in your specific Drupal and web development communities.  Be cognizant of your constituency.  Know:

• Who they are
• What they want and need to learn
• Their preferred learning style(s)
• Their capacity (time and money) to participate in training
• Their skill level relevant to your specific topic

Having a good sense of these attributes will help you answer the relevant questions:

• Do I/we offer a full-on multi-session class?
• Are developers or end-users a more likely audience?
• Will short workshops be better?
• Hands-on or lecture?
• How much should/can we charge?

Lab Hours: A Case Study (of sorts)

Our training program has started slowly as we have attempted to take stock of where we fit in our local Drupal and broader web development ecosystem.  We decided to take a full-spectrum approach as there were few opportunities of any type available locally.  It was clear that our community needed Drupal learning opportunities spanning the gamut from:  "How do you pronounce that droo-paul?" to "Show me hook-link-alter again."  While we cannot and should not attempt to be all things to all people and expect to be successful, we have come up with a system that supports a through-line of training for those that decide they want to enter the Drupal world and continue to improve their skills.  

To that end we sponsor the local TC Drupal Users Group, have intensive training series like our upcoming Drupal Jumpstart Training, offer short topic-specific workshops and have training opportunities built-in to our managed Drupal hosting support packages.  We've found one of our offerings, Lab Hours, to be the most popular and has become the center of our training continuum.  I'd like to focus on this model for the rest of this post.

In a nutshell, Lab Hours is our variation on the classic "study hall."  Our customers are invited to join us for a drop-in Drupal help session each week for 2 hours.  They bring their laptops and work on their site and receive not only our support but support and best-practices support from their attending peers.  It's a terrific opportunity for knowledge cross-pollination.  A community has emerged from the sessions and it has become a social as well as professional gathering.  An email list is active between meetings and provides interim support as well as a means for determining which issues and features warrant further exploration within Lab Hours and also via formal workshops or classes.

The structure of a Lab Hours session, such as it exists, is as follows:

• Everyone introduces themselves, the project they are working on, and an issue for which they are seeking help
• We write each issue on a whiteboard
• If warranted, multiple people group to work on a single issue
• Staff and attendees identify people/groups to work with and the session proceeds
• 15 minutes prior to the end of the session, we review the board and discuss progress on each issue
• Follow-up summary is posted to the Lab Hours section of our website for documentation and potential discussion

We've been attempting to continue the flow of learning via our Labtime email list and our website.  Unresolved issues tend to float to the email list for followup from a broader pool.  Resolved issues are documented as Tips and posted to our website.  Both staff and Lab attendees have access to creating Tips and are encouraged to do so.  Some of our better Tips are cross-posted to Drupal Planet.

All of this encourages an environment of skill-enhancement, community building and community support.  Our ideal situation looks something like this:

• A web developer new to Drupal takes our introductory intensive Drupal class series
• The developer joins our Alliance Program which includes hosting for their client sites plus Lab Hours attendance
• Their client sites utilize our managed build (Drupal Install Profile) and builds upon the best-practices
• As issues emerge, the developer utilizes Lab Hours, Labtime email list and advantagelabs.com to resolve and learn
• Advantage Labs receives recurring revenue from client sites hosting and support, which is much lower than an individual's cost, but enough to guarantee a sustainable support resource
• This revenue also helps Advantage Labs develop and improve Drupal modules/systems and offer them back to the Drupal community
• Because those modules and systems are piloted in a hands-on environment, attendees participate in building and testing new tools while Advantage Labs monitors how those tools function in the wild

Bottom line, our local Drupal community enlarges and improves;  the greater Drupal community benefits as well.  In a perfect world this can be a phenomenally efficient distribution of resources. Everyone participates at the level appropriate to them and moves along as their skills develop.  

We're still developing our training program and evaluating our effectiveness as we go.  We invite your questions and encourage you to let us know what you think and how you are approaching the challenge of providing Drupal training.  Comment on this post and/or send us a line.  It would be great to collaborate on training models and training opportunities.  And, see you at the next Drupalcon.