It’s been an ongoing tradition for our engineering teams practically since STRV’s inception — having an hour dedicated for everyone to meet beyond client projects. And for good reason.
As a digital product company, our engineers typically work in project platform teams. It’s easy to forget just how similar our daily routines are; we often don’t realize we might be working on the same problems. Sharing sessions remind us of this while sustaining the feeling of being a part of an overarching team — where the bubble of solitude bursts, and knowledge is spread amongst all of us.
But it’s not just about sitting down together and hoping for the best. There are ways to get a sharing session right, and we like to think we’ve pinned them down pretty well.
Here’s a look at our approach and how it all led to our Monthly Project Sharing.
The Issue Detected
In the past, our Frontend team of 25–30 people struggled with having a few individuals dominating the conversation for the majority of every team-wide meeting.
Any bigger group will naturally have a few highly vocal individuals. Then there’s the confidence of seniority, various levels of interest in a particular topic or the inability to properly moderate a session. All of this affects who takes center stage while others do the listening. This is to be expected — but it doesn’t have to be that way.
“Let’s refresh the meeting culture,” our team leadership said roughly two years ago. And so we decided to create a new ritual within this existing sharing tradition.
The goal was to provide space for equal awareness about everyone’s daily highs and lows, and to strengthen collectiveness. We settled on dedicating every 3rd Wednesday of the month to a new concept: Monthly Project Sharing. And ever since, we haven’t missed a single session.
We’ve made many observations over the past two years, and we’d now like to share them with you in the humble hope that you might be inspired to apply a similar approach with your team — no matter its size. We’re convinced that this seemingly simple, almost school-like ritual significantly elevated our team spirit. Who knows what it can do for yours.
The Concept Introduced
When kicking off the first Monthly Project Sharing in May 2021, we created the following guide:
Rules for the meeting:
- Aiming for every project to be shared in “first come, first serve” order
- ~5 minutes per project
- No need for slides, totally voluntary
- For projects with more people, everyone is welcome to speak
Content suggestions (pick any, no need to cover all):
- Project overview (product, client, team, tech) — if it’s a new project
- What was a recent challenge/success/failure?
- Is there any new tech you learned or discovered because of this project?
- Any soft skills you’ve practiced or gained on this project? (communication, organization, patience…)
- Any specific code solution you want to share?
- What do you enjoy the most about the project? What would you like to improve there? What are the struggles you face?
- Just demo the app
This list was shared in Slack a few days before the first meeting. We also put it into our team docs, so the expectations were clear for everyone — no matter when they joined us. From that moment, the new “team contract” (collective long-term agreement) was set.
We’ve stuck to the list ever since. Every month, one day before the session, we also share an overview of all ongoing projects with the group, tagging people so we have a clear roster. The moderator uses it as a checklist.
The Beauty of Rituals
The regularity of the ritual is key. We’re living proof that an explicit team contract can be upheld for years, despite all the unknowns and ever-changing priorities that time brings.
Our team has evolved. So has STRV. But the benefits of these sessions remain. Most notably, these benefits are:
- Building a strong common ground
- Providing a healthy push for everyone
- Creating room for opportunities
- Easing first steps and connection for newcomers
- Relieving pressure by clarifying expectations
Let’s share more detailed lessons learned based on questions that may be crossing your mind.
“Why monthly?”
A month is a long enough time for sharing specific progress. We’ve found it’s a healthy interval for keeping everyone up to speed and avoiding repetitive explanations of the same project. We also want people to actively and eagerly participate, instead of occupying multiple meeting slots a month — which would feel like a limiting, overly-frequent obligation.
“What’s the attendance rate?”
Our weekly meetings are generally not mandatory but recommended. Monthly Project Sharing is no different. Overall attendance depends on the topic but generally, it’s around 90% — and has never been lower than 50%. Since the sessions always aim to introduce a topic relevant to everyone, they usually have the highest attendance of any team-wide meetings. Which is so important for the feeling of collectiveness.
We don’t force people to be in the office for the sessions. Remote with a webcam is fine. However, to support in-person attendance, we have a team lunch on the day at noon; we order food — both in Prague and Brno — and eat together over Gmeet, even with those eating at home. It brings us together and sets the sharing mood up for the afternoon.
“What level of depth can you share in ~5 minutes?”
There’s more to this than meets the eye. You can plant a lot of seeds even in such a short time. Throughout the first months of these sessions, we gradually saw people continuing the conversation outside of the sessions — discussing both soft and tech topics that we’d opened up because they’d found common ground.
It’s had long-term effects, too. Initiating discussions and exploring topics deeper than ever before has become way easier. Our thinking has always been: If some learning comes out of these sessions, great. But that’s never been the main purpose.
“Does everyone always speak?”
We aim for that, but we’re not at 100%. Usually, it’s 80–90% based on the amount of people/projects. To keep that number high, the trick lies in strict moderation. The moderators (Frontend managers) keep a close eye on what’s happening on each project, therefore if no project member steps up, we call someone out and give them direction.
At one point, we noticed some people were preparing their updates in advance, only to end up not sharing them during the session. Nothing wrong with that. Still, over time, people in that situation started sharing their updates after the sessions via Slack all on their own, just because they felt the urge to contribute to the collective responsibility and the team contract.
“What if a project update goes on for too long?”
That was happening in the early months before we got used to the drill. We learned to keep this in check as a team.
First, the moderator began identifying such moments, pausing the monologue and proposing diving deeper during a separate meeting. Later, speakers began having “Oh, I’m talking too much, this goes deeper than I thought” moments as they grew more adept at scanning the room and perceiving people’s interest. All this taught us how to get the most out of every topic — often by transferring insightful tech challenges into separate meetings, where thorough knowledge sharing happens.
“Isn’t it always the same?”
Might be surprising, but not at all. It’s a living, breathing part of our culture. For instance, when a new member joins the team, they bring a new vibe and unintentionally raise the bar.
A junior once prepared beautiful slides with a story about his first project with us. It was the first time in months that someone nailed their preparation. Everyone was left speechless and even a bit ashamed, especially the seniors. It was so refreshing and brought sharing to a new level — organically.
Then there was the time an engineer instinctively stood up in front of everyone as the first speaker of that session; until then, we’d always spoken from our seats. Others followed suit, and we experienced performance-like sharing that solidified this “ritual” of ours as a safe space for practicing public speaking.
Improving the quality of how someone contributes during the sessions is also an occasional goal set up during performance reviews for our less experienced or introverted engineers.
“What if there’s a project you’re struggling with?”
Not everything is all smiles. Some projects are easier or cooler than others. Closing your eyes to this would be unhealthy and could create unrealistic expectations for the team. We all experience lows, and we all have to work on stuff that hurts and doesn’t always bring joy. It helps to share your worries — and alternatively, if you’re riding high, knowing about the pains those next to you face makes you more empathetic and grateful.
Our sessions are a place to both celebrate the good and vent about the bad. We’re proud to say that we’ve never resorted to trash talk about a project or client; all commentary is constructive, and it’s met with nothing but support from the team. We help each other find new angles in facing the problem, or just listen and hope to hear better news at the next session.
The Final Words
Retrospectively, we realize we may have been influenced by memories of literature classes at school. The early STRV meeting days came with a bit of subconscious defiance. We recalled those “I hope the teacher won’t call on me to talk about the book I read” moments, and we didn’t want to be managers that created a similar atmosphere. Our thinking was, “This is a job. Our projects are cool. We’re here voluntarily, and mainly — we keep it chill.”
We’re proud the Frontend team broke this status quo two years ago. Because this isn’t school; this is our craft, and we’re cultivating it together.
Not every Monthly Project Sharing brings high energy and shiny updates. We’ve had many silences, shaky voices, unexpected calls. But it all strengthens our team dynamic and fulfills that initial goal: provide space for equal awareness and strengthen collectiveness — via a strong ritual serving as a long-term tool for growing closer, staying human and developing our skills.
