Setting up a self-learning group in your company in 14 steps
So you’ve just heard about a new, cool, bleeding-edge technology. You want to learn it. After all, you know that programmers need to constantly broaden their knowledge, right? Right. You can just sit down on your own, learn it yourself and be proud of knowing it. But you think that it might be also useful to your company. Would it be worth spreading this knowledge? Maybe you’ll be able to introduce something new to your company’s tech stack? Who knows. So you decide to give it a try and create a group for learning that-new-thing. You don’t know how? Very good. Read on. Here’s a step-by-step guide how to organise a self-learning group, introduce a new technology to the company, find motivated people and help them have fun while doing it.
A little background
Every employee at u2i may use 4 hours a week of their time to do anything they like. It’s similar to famous Google’s 20% rule. The difference is that we’ve got only 10% (but we still have it, while Google changed its mind) and that this time doesn’t necessary need to be spent on something directly beneficial to the company. We can use it for anything, like developing side projects, doing tutorials, reading technical books, writing blog posts, playing with Arduino — you name it. One general rule is that you have to do something for your own development.
Self development time fits perfectly when we want to learn something new. Especially if that something is not immediately useful for our professional work. We believe also that the best results might be achieved when working together. That’s why we started experimenting with self-learning groups. These are voluntary groups of employees who want to learn something new together using their 10% time. Here are a few things we learned about how to get things going.
A step-by-step guide to a self-learning group
Are you ready to start your own group? Here are the ideas!
1. Be a leader
One of your goals might be to create a self-organizing group. That’s fine. Noble even. U2i has a long history of different collaborative initiatives. Some of them were successful, others ended after the first meeting. We don’t have a silver bullet for success, but we know for sure that having a leader at the beginning can help a lot. Someone to establish it, set the initial pace and care about where the group goes. When your group loses momentum, the leader is the person to step in and bring the fun back. You should be that leader. Keep in mind that will require some significant effort on your part, especially at the beginning. But on the other hand it also brings a lot of satisfaction.
2. Do the research
You already know what technology you want to learn. Now you have to do the research. Find out general information about it, what are its features, where it aims, where it might be useful, what are the pros and, more importantly, the cons. Get some general knowledge about the market, similar tools, competitors. Think how it can be used in your company. Be ready to explain your decision. If you want people to spend some time with it, you’ll have to convince them that it wasn’t a random choice.
Don’t go too deeply into the topic. You don’t have to gain any serious proficiency in it. It’s fine to say that you haven’t written a single line of code in your technology yet. Just be aware of its features and possible downsides.
3. Create a communication channel
A communication channel is a good thing even if you work in a small company (like we do). At the beginning it’ll be useful as a staging point for people interested in joining you. Later on you’ll use it for organisational purposes and for posting useful stuff regarding the topic of your group. From our experience it works as a good way to facilitate a constant discussion during the time between meetings. You can use IRC, HipChat, a mailing list, a discussion board or whatever works for you. We use Slack. It works very well as a general communication platform gathering all in-house conversations. When we form a new group we just create a new Slack channel.
4. Give a talk
Give a talk at your company about the technology that you chose (at u2i these kind of short presentations are called techspressos). Share the knowledge you gained during your research. You’ll get some immediate feedback on how people react and what they think about the technology. At the end announce the start of a self-learning group and mention the communication channel that you created earlier. Hopefully you’ll find some people ready to join you. You’re targeting those who are eager to learn something new, but maybe not motivated enough to do it by themselves. If they see that you’re going to take care of the whole process and give them an opportunity to gain some knowledge easily, they’ll automatically become more interested.
If you want to gain some inspiration on what this talk can look like you can take a look at my slides about cool programming languages. I talked about the recent, most promising, yet not very popular languages. My aim was to keep my colleagues up-to-date with the latest technologies and at the same time find people interested in learning the one I found most interesting — Golang. It worked great — a few days later the group was established and ready to take off.
5. Create an agenda for your group
Now that you’ve gathered your participants it’s time to create the agenda. At the very first meetings of the Golang group we didn’t have an exact plan for what to do. Nobody had written a single line in it, so we needed to start from the very basics. On the other hand we felt that sticking too long to the theoretical part would affect the group’s motivation. What worked best for us was to divide the program into two parts: the learning phase and the implementationphase.
During the learning phase you and your group will get to know the basics of the technology, familiarize yourselves with the tools and the ecosystem. One good way of going about it is to find an online tutorial or a course describing the topic and just follow it. That way you can let people learn on their own and use regular meetings only to discuss their experience and any problems they might have encountered. This part shouldn’t take too long, because people may eventually get bored with working with theoretical content only. What we find reasonable is to spend 3–5 weeks while meeting every week. That should give your participants enough time to get familiar with the topic in their own pace.
The goal of the implementation phase is to create a useful piece of software. The best way to learn is to use the knowledge in practice. Meetings during that phase will be used for designing, problem solving and coding. The length and frequency of the meetings may vary depending on the number of people, their involvement, the amount of free time they have, the specifics of the project and many other factors. Initially try not to put any time limits here. You’ll see how it goes.
6. Gather your group for the first meeting
Start with finding a good time in everybody’s calendar and create a recurring event. When it’s set it’s harder to skip it. Invite everybody to the first meeting. Prepare a list of recommended materials, links to documentation, cheat sheets and instructions on how to setup a development environment. Anything that can be useful to start learning as quickly as possible. Your participants will be happy to see that they can just focus on content, rather than searching through the Internet to find why some library doesn’t compile. A well prepared boilerplate can go a long way in this respect.
7. Post interesting stuff regularly
Look for blog posts, conference videos, GitHub repositories, Reddit news, new release announcements and any other useful content regarding your topic and post them on your communication channel. Not only will people use them to stay up to date, but also get the impression that something’s constantly going on. It’s usually very motivating when you feel somebody really cares.
8. Go through the learning phase
What worked best for us was to leave the meetings for exchanging thoughts and comments only. Ask people to do the tutorial (or any other content that you chose) between the sessions. This way everybody can think at their own pace and tackle problems individually.
On the meeting connect your computer to a bigger screen and use it to go through the material. Focus on things that you found particularly interesting or tricky. Make sure everybody gets general understanding of it. Encourage people to take part in the conversation. At the end tell the participants what the topic for the next meeting is. You can even ask them to do some coding as homework. Don’t be surprised if people don’t do it though. It’s normal. Make sure to politely remind them during the week about the next meeting and its topic.
Remember that the aim of this phase is not to teach people everything. It’s okay if afterwards they say that they still don’t know much about the topic. It’s only to show them the general concepts and places where they can find useful information. They’re gonna learn stuff for real during the implementation phase.
9. Encourage people to prepare something on their own
If you feel that your participants are eager to do something more, give them a chance. What worked best for us is the idea of lightning talks. They are very short (5mins — 10 mins) and focused on some particular small topic. Ask people to prepare and present them. The topic may be e.g.: which IDE to use, what are the most popular testing frameworks, what are the tools to build binaries or manage dependencies. Examples of cool projects done with the technology might also be interesting. Remember to keep it short and don’t be afraid to enforce this rule. It may also be a great opportunity for participants to train their public speaking skills, but still in a controlled environment.
10. Prepare for the implementation phase
This phase is where the fun begins. You’re going to implement some real stuff here. It’s very important to choose a good project. An ideal one would be both interesting for your group and useful for somebody else. Maybe there’s something that your company needs? A simple app to help with ordering food or office equipment? A scoreboard for your foosball matches or console games tournaments? A tool to provide content for your TV dashboard? A Slack bot? A browser game you can use to entertain employees or promote your company? Speaking of games, maybe a modern clone of some classic arcade title? There are many possibilities. Brainstorm it with your group. The general suggestions are that:
- It should be fun for everybody! Don’t let your people get stuck in some boring project, because they’ll lose the motivation.
- It shouldn’t be trivial or something that has been well described in articles over the Internet (like yet another blogging platform).
- It should be relatively small. You should be able to create a working solution in weeks or months.
In the Golang group we initially wanted to get involved in some open source project, but eventually changed our minds. We felt that we simply don’t know enough to make a meaningful contribution. And because we decided that doing something from scratch would bring more fun, we finally created a backend for a massive multiplayer galactic browser game.
11. Implement it
Start the implementing phase after you finish the material in the learning phase. This time you’ll meet your group to do some coding. It may be better to plan slightly longer sessions to have enough time to actually get something done. You may stick to your previous schedule or gather your group ad hoc, depending on how flexible everybody is with their time. When it comes to what the meetings should look like we found two options useful:
- Mob programming. One person is coding on a computer connected to a bigger screen and everyone else gives their suggestions and ideas. We weren’t convinced by this method, but it worked surprisingly well in our initial meetings. It’s the time when many people are still far from being fluent in the technology, so it’s good to do it together. Of course the number of collaborators is limited. We successfully tested it with up to 6 people, but your mileage may vary.
- Pair programming. This is one of the fundamental values at u2i. We do pair programming on a daily basis in our professional work. Therefore, it was quite natural for us to adopt this way of working. To make it happen, let people divide themselves into pairs and give them some tasks to do. It may not work well in the first meetings, because there is not much written yet and it might not be easy to distinguish separate units of work that can be done independently.
12. Generate some publicity in your company
It’s good when other people in your company know that your group works on something interesting. Make sure they have a chance to notice your efforts. You may prepare some kind of visual identification for your group in a form of posters, stickers, labels or anything else. It has two advantages: you make your group more self-aware and it helps to find new people willing to join you.
Remember the massive multiplayer game I mentioned earlier? It’s called Superstellar. It’s placed in outer space where players fly their spaceships. To create an atmosphere, the developers received paper desk stands with NASA-like names that symbolized some imaginary departments of our “galactic company”. We also prepared a sheet of paper with our project’s logo that we put on the conference room’s door every time we gathered to do the implementation phase meeting.
13. Your group lost motivation?
It happens. It happened to us several times. The most important thing is that you — the leader- are still motivated. Try to prepare something on your own and present it to the group. Maybe implement some cool feature in your app? Or show them some interesting talk? It’s important to remember that it’s your responsibility to take care of your group. And the general rule is: carry on even if there’s only one person left besides you. Motivation is contagious.
It’s essential to plan with an end in mind. People work better when they have some clear aim and feel better when they succeed in completing it. After some time of development sit down and choose a set features you would like to implement. This will be your target (or to use the startup world’s terminology — your MVP). Don’t go too far with it. It’s better to plan something smaller, but more reachable. Write down a list of chosen features and put them into some project management tool, like Trello.
Once you finish your MVP share it with the rest of your company. Prepare a presentation and describe what your group has learned, show your project and ask for feedback. Announce an official end of the learning group. That doesn’t necessary mean that you should stop working on the project. Based on feedback, people’s involvement and motivation you’ll decide if you want to continue the project or not. Maybe you’ll hand your project over to somebody else and establish a new self-learning group?
Curious about Superstellar? Take a look here.
Author: Michał Konarski