Over the past months, I’ve been considering writing about high performant teams, but every time I sat to write something, I couldn’t help myself but think how big this topic is. So I decided to split it up and address them in different posts. The first topic, and the one that I find the most important, is mastery.
Over the past decade, I had the opportunity to work with hundreds of engineers, from whom I learned a lot and made lots of observations. One of the traits I saw in most people and teams I interacted, was how much engineers valued mastery. Even with most people sharing this trait, a common topic in retrospectives and coffee talks was the lack of learning new things in their job. Inevitably, such teams suffered from other issues like lack of motivation, high turnover and etc.
Although mastery alone does not make a high performing team, it does bring an extra boost of motivation and fun to the team and could materialize in a high-quality product as well.
In my previous teams, I tried to share with my peers what I was currently reading, or the technologies I was playing with. Although this approach was very successful for me to build a good connection and relationship with my peers, it didn’t help much the team as a whole.
In my current team, I proposed a different approach from day zero: We make mastery as part of our team and our work. This translated into a new team ritual, that we called Hacking Sessions - a weekly 1-hour session every Friday afternoon.
Our initial idea was to have these sessions to watch tech talks, have a book club and etc, but this ended up being way more than that. We started to share things we learned in our private time, we discussed different approaches and designs for the project we were working on at that time, and more.
A couple of months on the team, I’ve noticed how much this ceremony had influenced our decisions and the way we interact with each other. We learned how to share ideas with the team, how to decide as a team which technical approach would be better to solve a given problem, and many more. I also noticed how much our team had a good bond and how much we respected each other, and I pay part of this due to how we invested in mastery since day zero.
Just do it
Do not over-complicate it, just do it. Having a weekly tech session in the team is a great way to invest in mastery, and this will inevitably help in building a better team and a better product. You do not need higher management approval for that, really :) How many hours are lost in meetings and other activities that do not necessarily bring value to your team?
Are you out of ideas?
If you find this idea interesting, I can recommend a list of topics that you could use as inspiration for your team:
- Follow the MIT Distributed System lessons and implement the labs (Thanks André for the recommendation)
- Implement a key-value database in a language you all find interesting (Rust anyone?)
- Read technical books
- Contribute to an open-source project you use at your company
- Talk about distributed-transactions, replication, consensus algorithms and etc
- Build a simple programming language
If you are curious, these are a couple of things we talked about during our Hacking sessions:
- Datomic & Clojure
- Functional programming with Kotlin + Arrow
- We read and discussed each chapter of the book Designing Data-Intensive Application
- We talked about Hexagonal Architecture and how it would fit in our product
- GraalVM, Micronaut, Quarkus
- and many more
I hope you find this post useful, and that it helps your team too. In the end, we are also here to learn and to have some fun. So make the best out of it!