Cross-functional teams, which work like micro startups within the larger organization, usually shine for their agility, employee engagement, and collaboration across different areas of expertise.
But ask anyone in a typical cross-functional team about challenges within their routine work, and you would likely hear the following feedback:
- I feel somehow stuck and always end up working on the same things.
- We are working in silos, and knowledge rarely permeates between teams.
- We are having real issues dealing with inter-team dependencies. We are stepping on each other’s code or duplicate implementations.
This struggle is typical in organizations that do little to nothing to connect function experts (such as Product Managers or Quality Assurance Engineers) outside of their teams.
At Staffbase, Chapters have been a key element for addressing the problems that cross-functional teams face because of their very nature.
We currently have eight Chapters at Staffbase[^1]. In the figure above, the teams are represented by the columns delimited by dashed lines. Each colored horizontal line represents a Chapter: a domain of expertise as well as a channel of communication and collaboration between specialists. It runs transversally to the cross-functional teams.
The main purpose of a Chapter is to work on strategy, direction, and knowledge sharing. It must remain aligned to the OKRs of the product organization.
Before we dive in and discuss the Frontend Chapter, I would also like to mention that our Chapters are:
- Timeboxed: Each member of the product org can dedicate 20% of their work time for the Chapter - preferably as a single day per week (at Staffbase we have chosen Mondays).
- Led by experts: The Tech Leads also meet on mondays to align about overarching topics, and they are leading the Chapter sessions as knowledge experts.
- Self-organized: Each Chapter consists of self-organizing and contributing members.
For coordinating work in the Frontend Chapter, we have established two meetings on Mondays: a kickoff in the morning and a wrap-up in the afternoon.
On Mondays, we start the day with the Frontend Chapter kickoff meeting. It lasts about 30 minutes, and this is where we take a look at our Chapter's JIRA Board and plan the day. We also gather new topics, and each Engineer can choose which group to join or which topic to work on.
The Chapter embraces an agile, iterative approach. For a few weeks, both the kickoff and the wrap-up meetings have been moderated by an Agile Coach as part of an initiative to foster a more focused environment. This has led to more efficient meetings and increased satisfaction among the attendees.
The kickoff gives an opportunity for everyone to plan future tasks, bring up new topics, choose a task for the day, join a working group or just ask for support. To provide more insight into the kickoff meeting, I am sharing below the minutes of a recent one. Some of the topics were gathered beforehand, and some came up organically during the meeting.
Minutes of a Frontend Chapter kickoff meeting
- Intro & Gather Topics (5’)
- Q2 Demo Session (5’)
- Which achievements can we demo at the Q2 demo session? Who would like to do the demo? => T.G. will demo IE11 deprecation and some other tombstones
- Chapter onsite Event at Staffbase Camp (5’)
- Do we want to come one day earlier to the Staffbase Camp in September and do something together? => enough people are interested
- Autumn Release Deprecations (5’)
- We could use the major update coming in Autumn to deprecate some old stuff, e.g. browser versions. Any suggestions? => F.A. is going to ask for further Feedback on our Slack Chapter Channel
- Planning the Chapter Day (10’)
- Refining Chapter goals for Q3
- Remove react Import - some more approvals are needed before merging
- Module Federation Presentation - M.Z., S.D., and M.M. will be busy polishing their presentation that we can attend at 5 pm today
At the end of the day, we come back together for a short wrap-up where everyone can share their progress.
Here are some recurring topics that the Frontend Chapter has been working on:
- adding type definitions to old JavaScript code / migrating JavaScript code to TypeScript
- refactoring, especially legacy parts of the application
- handling deprecations
- implementing Proofs Of Concept
Recently our most significant topic was the removal of all code related to Internet Explorer support. In doing that we not only removed several thousand lines of code but also reduced code complexity, improved maintainability and decreased the bundle size.
Modularisation is also a topic on which we are currently focusing. In an effort to modularize the codebase, a group of developers have been researching and getting us started with the implementation of micro-frontends. They have for instance worked on a proof of concept and prepared the presentation about Module Federation mentioned in the minutes above.
Letting anyone participate in discussions, choose a topic to work on or join a group to work with offers many growth opportunities. It gives everyone a chance to deepen their knowledge, get exposed to topics outside their usual domain of expertise, and gain a better understanding of the whole codebase.
Chapter days are also used to share general knowledge that will then flow back to the teams. For instance, once our new Design System was ready for production, the working group that was in charge of it gave a presentation on a Chapter day, allowing Chapter members to carry the information to their teams confidently.
On top of the knowledge gathered on Chapter days, teams also profit from the Chapter in other ways. The Chapter can, for instance, take charge of a topic that spans multiple team domains or that teams don’t currently have the capacity to work on.
The Chapter is the place to go whenever a Frontend dev or a team needs guidance, mentoring, or simply a missing code review. The Chapter’s Slack channel lets anyone approach all members of the Chapter easily.
The sense of belonging, purpose, and cohesion offered by the fact that Chapter days give everyone a chance to work with people outside their own team is a great asset for both the company and the well-being of its employees.
I joined the company while home office was the norm due to COVID restrictions, and I have found the opportunity to get in touch with people outside my team on Chapter days very positive. We recently had a big in-person event, and it was a real pleasure to meet the many colleagues that I would not have known without our Chapter days.
There are, of course, some aspects of Chapter work that need improvement. For instance, the Chapter gathered feedback that some developers with less experience sometimes do not know how to participate. Does this blocker simply come down to giving some people more time before they can contribute or feel psychologically safe in a group where they at first know just a few people? Or is the format maybe not inclusive to all? This is definitely something we are taking time to focus on.
Attendance is expected and encouraged but not enforced. As long as enough people take part in Chapter work, and the Chapter manages to fulfill its different roles, I would argue that this freedom is a good thing. Yet on some occasions, it feels like only a few people join. This can negatively impact the motivation of those who are more involved on those days. This also means, potentially, that the knowledge of some high-level topics does not break out of the circle of those who always work on them. So this is definitely something we are keeping an eye on.
Staffbase has been growing a lot, and coordinating the Chapter work over multiple time zones in a good way is something we still have to figure out.
A few days ago I asked some members of the Frontend Chapter what they think about the work of our Chapter. Their main thoughts were consistent with the points mentioned in this article: tackling important topics or technical debt that crosses team boundaries would be very challenging, there would be much less knowledge sharing happening if we did not have a Frontend Chapter, we would know way fewer people outside our teams, and we would miss a sense of being part of something bigger.
By (re-)establishing a deeper connection between the employees that belong to the same area of expertise, I see Chapters as a logical and very effective way to address some of the biggest challenges of cross-functional teams.
[^1] New Chapters can be created for inter-team purposes that are not addressed by existing Chapters, as long as it is not a specialization of another Chapter (because in that case it is usually better to create a sub-group).