Building Communities of Practice

Problem

As we started to grow, people became increasingly isolated and communicated only within their teams. When it was only four of us at the very beginning it was impossible not to know what was happening on the team. We were all in the same room, had lunch together, discussed every single thing, etc. This remained a norm until we were 25, or even 30 since we were working in an open-space office. Then we moved into a new building with smaller rooms that could accommodate only six people. Suddenly a disconnect in communication happened.

We noticed after a while that we were working on things that people from other teams we were also working on, without being aware of the overlap. However, the nature of our work is quite unique since we work with large biomedical companies building instruments for them. While those are different companies they are encountering similar challenges. We had to find a way to connect people who are working on the same problems but are not communicating day-to-day.

Actions taken

We came up with an idea of Communities of Practice that would connect people working on similar problems but on different projects. We started off with an experimental software engineering community with a plan not to make it too granular until people didn’t get used to the concept.

We explained to the people of the software development department that from that moment on, we would have our own community and introduced Confluence as a tool to enhance our collaboration in real-time. We started to document best practices, stories, experiences, etc. We also created a Q&A section where people could post a question that could be answered by anyone across the company. Moreover, every two weeks we would all meet in a spacious conference room where we had people delivering various presentations. People soon became quite engaged and we had volunteers who were keen to showcase interesting things they learned while working on their projects, or share new technologies, approaches, patterns, architecture, etc.

 

It seemed people were excited about the idea, and thus people from other departments also became interested in replicating what we were doing. Our colleagues from the testing department picked it up first, because they struggled with the same problem as we were. It didn’t take long for our concept to grow beyond our local office. People in Germany, Hungary, and Austria noticed that we were doing something great they also wanted to be a part of. That coincided with the emergence of the global pandemic and people went all online. It made it even easier for us to organize events online and bring a large crowd to attend.

However, things didn’t stop there. While our concept was spreading to include the leadership and requirements engineering department, we also noticed that people are grouping around different niches in the software development department. Some would be more interested in databases, processes, or architecture and we encouraged them to start their more streamlined, smaller communities.

We are overall very pleased about how things unfolded. We saw vibrant cross-organizational communication emerging and a huge improvement in our knowledge management system. Whenever someone would do something new or interesting it would be widely distributed. Also, we created a system where engineers could rely on support from other engineers, which indirectly enhanced inter-team communication.

Lessons learned

• A lot of effort is required to build a community of any kind. We introduced a community lead, a person responsible for the planning of the events and inviting people which helped fuel the enthusiasm. Indeed, people were interested and excited, but that alone wouldn’t be sufficient to build the community. Before we decided to introduce a community lead role, we had volunteers who made sure that we always had people willing to share their presentations. We always had a couple of highly enthusiastic people on whom we could rely to come up with a presentation if no one else would apply but designating one person made all the difference.
• When we started our software development community we announced it as a forum to share the problems and solutions with other teammates. We knew that many people were not comfortable with speaking in public, so we assured them that being surrounded by their own teammates is the safest environment that can be. It took us a while to encourage them because most were quite reluctant to do it. So, we decided to help people with their presentations.and the community lead would help them with preparing the presentation and also rehearse with them.