How does your workplace cultivate an environment of team development? How do you make sure your engineers have time for creative ideas and professional development, all the while meeting sprints, deadlines and deliverables? While branded photogenic team building activities are common in many tech companies — especially with rapidly growing teams, this strategy fails to help grow together as professionals and misses the aim in the long run.
For long, I’ve been toying with such questions, asking myself — how can companies keep “the fun bits”, but also cultivate purpose and a culture of self and team professional development. In this post you’ll find the pilot we’re launching at Swimm: the main goals of such a pilot and why we believe in it, as well as the execution strategy. We will follow-up and share our experiences in future posts.
The why: delivering code excellence
Professionalism. First, we want to create a culture where all of our team members learn new things, on an ongoing basis. To become professionals, we need to keep learning all the time. To stay happy and challenged at work we need access to resources, and need our managers to invest in our development.
Innovation. Second, reviewing together new topics and brainstorming on how they can be integrated into our products will provide new ideas and make us constantly rethink our current approaches.
While thinking about a way to achieve these goals, I was looking for best practice, study cases and models that worked well or gloriously failed in other places in the tech industry. Specifically, I was inspired by this post by Idan Bassuk from Aidoc. I contacted Idan and he was very kind to answer all my questions. I learned that they’ve been continuing their “Deep Snips” (where one of their team members learns a subject and presents it to the team) for the past 3 years, and that he still believes this method helps achieve its goals. I learned from their experience that many of their talks resulted in actual impact to their products. This gave me confidence that this method can indeed have a meaningful impact, and I was now more eager than before to put this to the test.
The How: Swimminars X 2 weeks
Swimminars. Every other week, one of our engineers will get to learn something new that they wish to dive deeper into and learn. It can be about anything at all, as long as it’s technological, and can be applied to our product(s), even if not in the foreseeable future. Then, the engineer will give a lecture, sharing their research and new knowledge with the team. After every session, we will also publish a blog post, summarising the lecture for our community or new hires to use if they wish.
Technicalities. We plan to divide the session into two parts — the first will be technical, an in-depth overview of the relevant subject (will be covered on our blog posts). The second part will include holding internal discussions on the possible utilisation, adoption and impacts of the topic on our product(s). Are we already relying on some of this knowledge? Can it help us tackle a current or future issue? Perhaps we need to consider implementing it now?
During the two weeks of the engineer’s turn, (s)he gets as much time as needed to learn the subject and prepare the lecture. This will be prioritised over other tasks, and we assume it will take between one and two days. This is a huge commitment — with all the tasks that we have as a startup, every day is precious. Still, we decided that the impact we are hoping for is so valuable that it’s worth the price, and that we are willing to make the experiment.
Piloting: managing expectations
Risks. Yet, as always, it’s easier said than done. Indeed this can go wrong in different ways — time management vs efficiency, getting to a high level of interesting presentations and useful technological insight, or getting every one’s voice heard on the team in a manner that compliments them. It’s a learning on the go activity. So we’re up for a team challenge.
Upsides. For the duration of our team pilot, every other week, the entire dev team will get to learn something new while taking turns deepening knowledge, improving writing and presentation skills and becoming experts within the team on their Swimminar topics. This team exercise will provide each engineer individually and the team as whole, positive experiences of success. We hope.
I will be the first to give a Swimminar — specifically, on git internals. How it goes from there, only time will tell. We promise to report back on how this experiment is working for us. Stay tuned.
Swimm is a tool helping engineers contribute to any codebase faster and better with automatically generated hints and codebase insight.
To learn more about Swimm, sign up for a 1:1 Swimm demo.
