It has been about a year since we started the guilds in trivago Software Engineering department in Düsseldorf. You can read about the time when we started here.
I would like to share with you some things we have learnt. We have three guilds active at the moment: PHP, JavaScript and UX/UI.
What Is a Guild, or a Community of Practice?
Communities of practice are found within the field of Knowledge Management. The latter can be defined as:
the process of creating, sharing, using and managing the knowledge and information of an organization.
Wenger[1] talks about the three “waves” in the field of Knowledge Management:
The field of knowledge management has gone through a first wave of focus on technology. A second wave dealt with issues of behaviour, culture, and tacit knowledge, but mostly in the abstract. A third wave now is discovering that communities of practice are a practical to frame the task of knowledge management. They provide a concrete organisational infrastructure for realising the dream of a learning organisation. [emphasis added]
In the same book he also provides a definition for Communities of Practice (CoP):
Communities of practice are groups of people who share a concern, a set of problems or a passion about a topic, and who deepen their knowledge and expertise in this area by interacting on an ongoing basis. [emphasis added]
Why Do We Need Them?
In a rather big company like trivago, people work in multi-disciplinary teams. In each of those teams there are usually developers, product owners, quality assurance, designers, agile coaches and more, depending on the purpose of this team. This structure is beneficial for product development, since it encourages the collaboration between the various departments and people with different expertise and avoids knowledge silos between departments.
Now, there is a potential downside of such structure. Yes, I said “potential” downside. If not taken care of, it could turn into a real weakness. If there is no space for the people with similar expertise to share experiences and learn from each other, new knowledge silos will be formed.
In this case, there needs to be a way of creating and maintaining the knowledge of the company as a body. The guilds provide this space. People working in different teams, who perform a similar role, can collaborate, set best practices, learn from each other, solve problems as teams, and drive actions as a cohesive group.
Lessons Learned
Over the course of the year 2016, many things were made clearer to us like: how to better organize this work, how to choose topics for the group, what can create value for the company and what not, and so on.
Lesson 1: Transparency Is Important
When doing any kind of work which goes across the company or department, it is important that everyone involved in or affected by this work is aware of it and can understand the value. In order to increase transparency, we strive to have a clean documentation of every meeting and working group, as well as summary updates on our internal social network website.
It is important also to have a clear defined agenda for the meetings. That way, people interested in specific subjects could join when that matter is discussed.
We use Slack as the main communication channel. There we have one public channel per guild, where many discussions are held.
Lesson 2: Coordination Is Important
The coordinator acts as a facilitator. He aims to bring people together with a healthy set of topics to discuss and take action.
He needs to be in touch with the members of the guild frequently in order to discover topics that need to be addressed by the group. He would also pick some people to help organize the meeting if needed. It is his reponsibility to do most of the organisational work like setting up the room and inviting everybody.
The coordinator needs to be sensible to the group’s interests. This will allow him to discover the most valuable topics to bring to every meeting. This defines which kind of value the group will create.
Lesson 3: Choose the Topics Wisely
If we are inviting every developer to join our meetings, it is important that this hour is effective. The topics should create value for all participants and for the company.
In the section “The Early Stages of Development”[1], the author mentions, amongst others, one thing that should be avoided when starting a Community of Practice:
It is tempting to begin by “getting the house in order” and reorganising all this material, but this generally does not energise the community. Focusing on current problems jump-starts the community with high energy issues. Heavy documentation responsibilities, particularly at the beginning of a community’s life can easily kill it. They make participation a burden, another action item or chore to do.
We could have avoided some issues in the beginning if we had followed the advice given above. At that point we didn’t know exactly what kind of topics to bring to the group. Throughout the year we had meetings which did not match our expectations in terms of value creation. We learned from them and improved our practice. Then we had many more meetings where everyone was satisfied and learned something that they could apply in their daily work.
At the end of every meeting we ask for the feedback of the group. It has always been valuable feedback which helped us to make the next meeting better and more valuable.
Lesson 4: Avoid What Is Easily Avoidable
It is the responsibility of the coordinator to talk to people to find out relevant topics to be discussed and assign people to their role in the meetings (such as: presenters, secretary or time keeper).
Sometimes we’ve encountered problems such as “the projector is not working” or “the room is too small for the group” or “the room was not booked so we need to find another one”. Those are easily avoidable by the coordinator. If not avoided, they decrease the motivation of the group over time and can give the impression that the community is not working seriously or organised enough.
This was definitely not a big issue, but something to point out that can be easily avoided.
Lesson 5: Promote the Works and Achievements
It is the duty of every member of the guilds to promote their activities to their peers. The company might be too big, and this group effort to promote the activities is very beneficial. When promoting it, focus on the value and benefits of the community.
Talk about the last meeting and achievements. Post them in a channel where everyone can see. Write summaries of the latest achievements and share that with your company. That way the activities done in the group will become visible and, therefore, more people will be interested in joining the guild.
Share the agenda of the next meeting ahead of time. Doing so, more people can know about it and join if the topic is in their interest. They can not know if the topic is in their interest if the agenda is not prepared in advance.
Lesson 6: It Is an Open Community
That is part of the nature of a Community of Practice: to be open and voluntary. It is fine if not everyone participates in the meetings and working groups of the guilds.
We have seen that participation fluctuates depending on the topics prepared for each meeting and working group, hence “Lesson 3: Choose the topics wisely”. If there are no topics previously defined for a meeting, don’t be afraid to cancel it.
Engineering Culture Is Improved
With this structure in place, which fosters knowledge sharing and collaboration, a new light was shed on our engineering culture. Acting as a team towards shared objectives is helping us to deliver better quality software.
We had some impressive achievements when we improved our work as a big team. Despite the fact that we have eight teams working in the same code base, we could steer the development into the right direction: improvements on the architecture, removal of old code, reduction of the code size which is delivered to the browser, improvements on performance, improvements on metrics like “time to first byte” and “time to interact” metrics and so on.
You can read more about some of the work driven by the guilds in these blog posts:
- Large Scale CSS Refactoring at trivago
- Speeding up webpack performance with parallel builds
- Prioritizing resources for a faster app startup
We, the engineers, are proud of those achievements especially because we own them. They were initiated and driven by us till the end, in cooperation and alignment with the teams of the guild participants.
The Boat Continues to Sail
Since it proved to bring many benefits to our teams, the work with the guilds will continue in 2017. There are some ideas for creating new guilds, for different areas. We also want to improve the guild directory documentation. This will enable everyone to see all the guilds and activities that are existing at the moment.
Perhaps we will talk about it again here in our tech blog in a few months, stay tuned.
References
[1] Wenger, Etienne C., McDermott, Richard, and Snyder, Williams C., Cultivating Communities Of Practice. 1st ed. Boston, Mass.: Harvard Business School Press, 2002. Print.
Follow us on