At my last organization, I was impressed by the number of developers and their active participation in the local development community. Many were regular attendees at local user groups and code camps. A few even had aspirations of becoming presenters. So much so that they had been attending Toastmasters during lunch breaks to improve their public speaking. As their supervisor, I felt I should and support them in any way possible. This gave me the inspiration for the Continual Improvement Sessions.
Continual vs. Continuous
Just because I know someone reading this is going to question the vocabulary…
From Wikipedia’s entry “Continual improvement process”:
In English-language linguistic prescription there is a common piece of usage advice that the word “continuous” should be used for things that are continuous in a way literally or figuratively equal to the mathematical sense of the word, whereas the word “continual” should be used for things that continue in discrete jumps (that is, quantum-wise). When this distinction is enforced, it is more accurate to speak of “continual improvement” and “continual improvement processes” than of “continuous improvement” or “continuous improvement processes”.
Now that we have that out of the way, here’s how I set things up…
Continual Improvement Sessions
I reserved a large conference room every Friday from 3-4pm. A meeting request was sent to everyone in the IT Staff with request for presenters. I invited everyone including systems administrators, quality assurance, development, and project management to attend. The more staff members in attendance, the better chance of participation and adoption as long as the presentations were kept short and everyone had a chance to contribute. The guidelines were simple and the attendance was voluntary (but strongly encouraged).
Guidelines for the Presenter
- Choose any topic related to software development. Including, but not limited to, programming, quality assurance, server management, SDLC, project management, etc.)
- Presentation should be 30 minutes or less.
- Slideshow/PowerPoint/visual aids are encouraged but not required.
- Make yourself available for 30 minutes after the presentation for questions and open discussion.
Guidelines for the Participants
- Be positive and supportive.
- Show up with an open mind and excited to learn something new.
- Participate by asking questions and joining in the discussion.
The Results
It took some effort to recruit the first presenter. No one ever wants to go first. I found a willing candidate who chose to speak on jQuery’s Deferred and Promises. His presentation was complete with code samples and a slide show using Impress.js. To my delight, the first presentation was professional quality.
I had to rally the team in attendance to the first session. The invite was kept listed everyone as an optional attendee, so folks weren’t sure if it was approved. After gentle coaxing, I had all of my of my team and members from a few other departments in attendance.
The presentation went perfectly. The 30 minutes I allotted for Q&A extended to nearly 2 hours. They loved the topic and the opportunity to learn so much that they stayed late on a Friday! If that doesn’t mark success, I don’t know what does. Even though his presentations set a high bar, I had no shortage of willing presenters after that first session.
It proved to be a fun and positive learning environment in which people could learn new skills, including public speaking and gain confidence and respect for their peers and themselves.
What I Learned
- Many IT professionals love learning. Show them something new and useful and it’s like a watching room full of kids on Christmas morning.
- Many IT professionals like showing off. I was surprised at how many folks signed up to give a presentation. Being in a friendly room of peers alleviated much of the apprehension of public speaking. It gave a shy developers the opportunity to build confidence among their peers, and confident developers the change to spread their knowledge.
- The conversations that took place after the presentation proved to be more valuable at team building than the presentation itself. Having all levels of developer, sys admins, quality assurance, and management talking freely about technology, their side projects, and experiences brought folks together in a way I hadn’t anticipated.
The cost of holding a voluntary one hour session is minimal making the return of increased morale and teamwork more than worthwhile. I would love to see more companies adopt this type of community learning within their organizations.
