Never miss your Knowledge Sharing again!

We all know that the habit of continuous learning plays a significant role in the IT world. Sometimes new projects that we start give us the opportunity to try out the latest solutions or even require us to explore previously unknown areas. It seems to me that with more frequent project rotations, learning is a natural consequence. But what if you don't start new projects every few months?

At RSQ Technologies my team has been developing the same application for over three years. For this reason, we do not have the opportunity to try the latest hot technological solutions every few months on the new codebase. The important aspect of our work is to keep up with programming news, share this knowledge within the team, and not be left behind. Three years ago we started a regular Knowledge Sharing meeting which form has changed many times. Every few months we also provide the space to discover more complex topics and put them into practice.

In this article, I will describe how the way of acquiring new knowledge and sharing it within our team has evolved over the years. What worked for us, and what ideas turned out to be a flop.

Did meetings without any specific plan work out? As you might have guessed — not really. We expected to receive a huge dose of knowledge every Friday but unfortunately, that didn’t happen. We could more or less profit from those meetings just because we were a group of only 4 people at the time. Nonetheless, I can easily recall the sessions when we just lost our time. Sometimes no one found an article worth paying attention to. Other times, the only interesting materials found were too demanding to read and present in one hour so they were skipped.

Despite all the disadvantages of this approach, today I think we made the right decision by meeting initially without a plan because at least we started doing anything at all. Sometimes to start is the most difficult part of the process — at least, for me. Over time, we learned in practice how to improve our meetings and what we really expect from them.

After several unproductive meetings, we agreed that our basic mistake was not preparing for them in advance. In order not to burden all team members with weekly preparations we assigned one person a week responsible for going through all the articles from the selected newsletter. They would then present them during the KS meeting. Every week someone else was on duty to keep us up to date with the Android world. Our meetings became more organized which facilitated the acquisition of knowledge.

After some time we were surprised by the improvement of our presentation skills because of regular talks in front of an audience. This applied to all team members, no matter what skills they started with. This skill improvement was an unexpected side effect of these meetings, however, I would say that this has become my favorite profit of them. Learning how to present and explain ideas to others in a way that is understandable to everyone is priceless.

Despite all those pros, a big disadvantage of this solution was the enormous amount of work that one person had to put into the preparations for the meeting. For me, it was at least 3–4 hours which I was not always able to find while studying and working.

After about a year of experimenting with the form of KS meeting, we finally found something suitable for all of us. It is a practice that is still used today.
The way it works is that each team member has 15 minutes to present whatever they want. In most cases we talk about technical news, however, the content that is presented may also concern soft skills like communication, leadership, work planning, etc. The aim of the 15-minute presentation is not always to teach the rest of the group given technology or library. Often we just want to signal that such a thing exists so it would stay in the backs of our heads and that we can come back to it when we are in need of it.

When an hour-long meeting was conducted by one person, our main problem was the amount of work and time that was required to prepare yourself for it. It was often quite overwhelming. Preparations for a 15-minute presentation are not like that anymore. This time I don’t feel overwhelmed, it’s more like fun.

We are aware that just talking about some technology or programming patterns during our meetings is not nearly as valuable as using it in practice. That is why every quarter we devote an entire workday to the practical exploration of technologies that interest us. So far each of these R&D days has been different from the previous ones. I will briefly describe a few of them.

During the first edition of the R&D day, we allowed individual team members to freely choose the topics to explore. Most of us started by going through the tutorials we prepared earlier. Everyone chose a different field of interest and some of them were:

From the perspective of time, I see that the best choice was made by colleagues who chose not very extensive topics like static analysis library or new layout type. These were topics that could be learned and roughly introduced to the project in 8 hours. The explorers could immediately notice the results of their work. Colleagues who chose less broad fields of their exploration were definitely more satisfied with the results of that day.

Another formula of the R&D that we organized was watching interesting conference talks for 8 hours straight. Each team member proposed some talks so we could create a playlist with something that fits everyone.

I think that an important aspect of that day was that we managed to organize it outside the office. We met at the house of one of us who has a large TV and a comfortable sofa. Getting out of the place where we spend so much time every day and which we associate with our daily routine made it seem more special to us. We haven’t reached the level of excitement that we usually get at real conferences, but I think we’ve moved into that state at least a little.

For the next edition of the R&D day, we had a completely different idea of what we would like to do. We were at this point in the development of the project that we all felt that we had to rethink its architecture and validate the decisions we made a long time ago. As the project grew, we had to grapple with the old bad concepts more and more. We decided that it would be helpful if the topic of the next R&D day would be related to the architecture. The plan was to implement one simple app using different popular architecture patterns like MVP, MVVM, MVI. Everyone could choose the pattern that they always wanted to explore. The application had to be really simple so that we could do it in 8 hours. It displayed a to-do list, a random joke downloaded using the REST API, and the popup. Before that day one of us prepared the mockups of the app and found some free API to use.

The last hour of the day was intended to present the code and discuss it. Of course, not everything went as well as we planned at the beginning and not all of us finished the whole app. Even if the app wasn't fully completed each of us could present the general approach of the chosen pattern. We didn’t become experts in selected architectures, but that was never the point. Writing the code for 8 hours in a different style than on a daily basis and not being limited by the frame of our project opened our minds to other solutions. Gaining this border perspective helped us to start further discussions about changes in our business application.

This edition of the R&D day was much more valuable to me than the first one. Focusing on one common issue during that day worked far more for us than being dispersed over many different topics.

As I said earlier - never miss your KS meeting again!

Making a habit of learning and knowledge sharing allowed us to systematically equalize the level of knowledge within the team. When we get into the routine we can discover approaches that surprise or inspire us. Our meeting takes place every week, no matter if we are in a rush to the next release or not. If we would wonder whether there is time for this meeting or not there would always be some reason to cancel it — there is always some deadline. Therefore we never even consider canceling and I also encourage you not to.

If you don’t run something similar in your team, start even if you are not convinced of the formula that is on your mind. The formula will change many times anyway and will adapt to the possibilities and expectations of the team. I encourage you to give it a try because I am sure that you will quickly notice how you benefit from it. We experienced the first benefits after just a few weeks and we can still feel them today. Good luck!

Related posts:

Incentivizing and Financing Commercial Building Retrofits Can Help to Deliver Only 1.5degC of Warming While Creating Millions of Jobs After 10 years working on decarbonizing buildings with the…

A successful entrepreneur should keep an eye on trends and changes and how they affect the business world. In the 21st century, several trends have emerged that entrepreneurs should be aware of and…

This is the fifth in a series of articles that illustrate how basic design principles can improve information display. The previous article focused on how your audience can influence your chart…