Back to resources

Building Communities of Practice

Internal Communication
Collaboration
Team Processes

19 May, 2021

Cristian Cătană
Cristian Cătană

VP of Development, Romania at STRATEC Biomedical

Cristian Cătană, Head of Software Engineering at STRATEC Biomedical, describes how he contributed to building Communities of Practice that encouraged cross-organizational communication and the exchange of best practices.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Building and Maintaining Company Culture: How to Scale Teams Accordingly

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

Managing Different Time Zones: Inclusive Collaboration Methods

19 May

Jonathan Belcher, Engineering Manager at Curative, shares an unknown side of synchronous communication tools and advises managers on how to handle a team that’s spread across the globe.

Remote
Internal Communication
Collaboration
Cross-Functional Collaboration
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Creating a Company Culture That Balances Helpfulness and Productivity

16 May

Alexis Philippe, Vice President, Product & Engineering at Amilla, describes his one simple rule for creating a culture of helpfulness that doesn't disrupt productivity.

Mission / Vision / Charter
Company Culture
Collaboration
Cross-Functional Collaboration
Alexis Philippe

Alexis Philippe

Vice President, Product & Engineering at Amilla

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.