How to Structure a Learning Group at Work

Zoe Madden-Wood ·

With any field, and especially programming, learning is integral. Technology changes. The field of programming is vast. To be a good programmer, you need to continue to learn and develop. In addition to learning outside of work, co-workers are often excited to learn together at work or through work. I know personally, I’m a social learner and enjoy the camaraderie that comes from struggling through a new topic together.

Over a year ago, I started an internal learning group. We meet every two weeks and discuss different topics in computer science. It occurred to me that during my time here, there have been several communal groups in place for learning new things, and I thought I’d take a moment to discuss some of the benefits and downsides to the different strategies of learning at work and offer some advice on starting your own internal learning group.

Different structures for learning groups

  • Following a course together
  • Creating your own curriculum
  • Reading and discussion group
  • Lunch lectures
  • Lightning talks/show and tell
  • Guest presentations

Following a Course Together

So, you’ve found a Tensor Flow class that you’re taking and it turns out someone else is too. You start a channel and you all keep each other motivated to finish the class. It’s a bit like a workout buddy. You can do things to make it more interactive — watch certain videos together or have coding time altogether — but barebones it’s a chat channel with a group of people to reach out to and commiserate with.

Pros: Taking a new class is a lot of dedication and a great way to learn new things. You can discuss what you’re learning with your peers in a place you might be likely to use that knowledge, which means it’s more likely to be internalized.

Cons: A lot of time outside of work. If you were ready to make that commitment anyway, it’s great it’s acknowledged and that you have a closer support forum to help you through the class. It’s a good option for remote teams as you can mostly do this through Slack. There’s a high likelihood some people might drop off at least partway through.

I’ll note that this can be an incredibly small group. My friend and I started following a databases class during lunch one day to get better at queries. Essentially we were course buddies, instead of a course group.

Creating Your Own Curriculum

One of the new technologies we got really excited about here at Carbon Five was Elm. Elm is a functional programming language that compiles to JavaScript. A great way to learn a new programming language is to build a basic app in that language. There are a few Elm tutorials out there, but we wanted to learn specific aspects of the language and have it match the app we were making. The leader created a tutorial on Github and taught a 5-week session on Elm.

Pros: Super hands-on! If you’re creating the curriculum and need to explain it… well, teaching is the best way to learn.

Cons: Rolling your own curriculum is a LOT more work. Timeframe needs to be short, as sequential sessions are hard to keep people going to. If someone gets sick or has a work meeting, then all of a sudden they’re a week behind and the next group meeting might not make sense, which creates a greater risk for drop-off.

If you want to go this route, but don’t know where to start, a good place is other curriculums. Often, even if you don’t want to follow someone else’s, you can take sections here and there, and see how they flow from one subject into another.

Reading and Discussion Group

We structured an internal reading group around reading computer science papers. People would post a paper to the chat and I’d keep track of them in a list. We’d vote on the next paper, read it, and then discuss it at the meeting. We’d use the paper’s structure to guide the discussion of the group and read through any difficult parts. Since we are working in development, we’ve sourced some of our papers from (Github’s papers we love).

Pros: This is reasonably distributed and egalitarian. Anyone can suggest a paper/blog. It’s not that much work. It works on understanding new concepts and explaining them. This may be great at an office where most people are siloed and there’s not much chance of discussing programming ideas with one another.

Cons: Not hands on.

Lunch Lectures

At Carbon Five, we’ve often had co-workers give presentations each week. We rotate speakers and the speaker gives a half-hour presentation on a topic of their choice. There have been many topics related to our domain, I saw a recent one on an excellent Redux pattern for instance, but Carbon Five has also encouraged people to share knowledge on whatever is interesting and important in people’s lives. I’ve really appreciated this from the standpoint of acknowledging that co-workers are whole people with awesome lives and amazing talents outside of the amazing talents they display at work. But I’ve also just found I’ve learned so much that inspired me, from song-writing strategies to bullet-point journaling, to clay glazing.

Pros: Highlights what people know and gives a chance to learn from one another. Helps those that are giving presentations at conferences have a supportive practice session.

Cons: Not everyone is great at presentations and may find them intimidating.

Lightning Talks/Show and Tell

This is giving short talks and can be used in large groups or as a structure small team exercise. I’ve seen this done as a generalized learning group across several dev teams. I’ve also seen it targeted to more of a team-specific code review show and tell. In the first case, you can bring anything in that is of interest and the object is learning. In the second, you’re trying to show work you’ve already done so that fellow programmers can propagate those patterns within your code, or know that a resource exists when they get stuck on the same thing you did. You can also introduce what you think would be a good pattern and explain it in advance so you can get team buy-in for code refactors or new code directions.

Pros: Highlights what people know and gives them a chance to learn from one another. A good way to distribute internal knowledge. It can build up confidence for giving presentations by being a smaller intro.

Cons: Same as lectures, not everyone is great at presentations and may find them intimidating.

I’ll note this works especially well in situations where the team is overall more junior because it allows you to have small presentations on incremental knowledge, like “Ruby’s #.negative? and” and “our new wrapper around this API” instead of “let me tell you about my implementation of Raft”.

Guest Presentations

Sometimes you’d like to hear from outside your organization and bring in new skills and experiences. Having guest presentations is a great way to do this.

Pros: Generally of high interest. Brings in external expertise that may not be available within the organization.

Cons: Difficult to coordinate. Difficult getting good people to give talks. Sometimes those giving a talk will also be trying to sell you on using their product. However, if you’re trying to use their product, that could be downright useful.

Making it Work

Now that I’ve run through the list of different types of internal learning groups. Here’s my generalized advice on how to set that up at your own organization.

  1. Create a community. People don’t attend due to just the topics, they join because they want to spend time with people (while learning the topics). Especially if it’s a discussion group or a course you’re following, have a chat channel. Post to it consistently. Respond to people. This will encourage people to come back.
  2. Aim for at least one other committed person. Generally, with any distributed group, you’ll have some people that will only occasionally show up. Often other obligations get in the way and truthfully, people’s interest waxes and wains. Instead of canceling constantly or just postponing when you’re likely to have lower attendance, figure out what the minimum number of people will need to be, and if you have that number, go for it. If it’s a discussion group, all you need is one other person. If you can find that one person to always show up, then that level of consistency will help keep the group going and keep people feeling motivated to show up.
  3. Aim for distributed leadership. It’s a lot of work. If you distribute the leadership, more people will care and that’ll keep you from feeling too frustrated. It also makes it more fun. Have someone else lead the discussion group. Have one lecturer prep the next lecturer. Find ways to make the group self-sustaining. This may be by creating artifacts or documents on how to run the meeting.
  4. Time it right. Ideally close to lunchtime, so the workday is already broken up, or at the start or end of day.
  5. Keep it at the right rhythm. Lectures at an office can often be once a week. Discussion groups where you need to read a distributed systems algorithms paper needs a bit more time in between. My personal philosophy has been to keep events a rare occasion people look forward to so that they’re really jazzed to attend the few sessions that happen.
  6. Don’t be afraid to stop and restart. Participation drops off during the holidays. Internal lectures run through people’s topics of things to say. Deadlines can sap creative energy or leave no time for even a lunch lecture. Don’t be afraid to pull the plug for a while and take a break. It’s not a commentary on how good of a job you’ve done or whether people found it valuable. We’ve gone on sabbaticals for our internal lectures, including a few month break for our discussion group. When we restart something, often people bring a new level of enthusiasm from the good memories they had in the past or get reinspired by the idea. And be sure that when you restart, you re-advertise. You may bring in people that previously said no, and find someone new who is unexpectedly jazzed about it all.