by Axel Schulz, reading time:
Welcome to the tech blog of the gematik! We know that starting a blog in 2022 is by no means innovative. But sharing knowledge is part of our DNA! We do it internally with our fellow developers, testers, and product owners - and we do it externally by sharing code and specifications on GitHub.
When I started as Director of Software Engineering at gematik, I was overwhelmed by how much the organization is focused on learning and sharing knowledge. Constant learning is essential!
Learning together is essential (Photo by Christina Morillo)
You may not call it learning, but extending your knowledge beyond what you already know is the core driver of our evolution as humans. The ancestors of Homo sapiens grabbed two stones and noticed that they could form a sharp blade by clashing them together. We learn through experience, and as an organization, it is your job to enable and drive learning. Here are a few examples and what they did to our team.
Every Friday is Code-Brunch time! It’s a full hour when some developers present a specific technical topic or challenge to the rest of the team, including testers and architects. Sometimes more than one topic is covered, and sometimes it takes only 10-15 minutes. But it’s a fixed date in everyone’s calendar where we gather for learning. For those who missed it, we save a SharePoint recording to keep our colleagues up-to-date.
Everything around coding and DevOps! We had sessions on how to do proper code reviews, mobile development, encryption, infrastructure-as-code - you name it; we had it! Some of these things will pop up eventually, sooner or later. We also present interesting new tools and frameworks which help us kill two birds with one stone: we monitor the market for new technology and share relevant knowledge.
First, we started in 2020, and it’s still part of our culture. So far, we have done 127 sessions, and the slots for this year are already booked. I think this counts as pretty successful. On the other hand, we hear that developers are using what they have learned in their daily work within the product teams, and nothing is more satisfying than hearing someone say, “I tried what you showed last Friday, and it helped me speed up my work enormously!”
One Friday per month is reserved as a voluntary Innovation Friday. Developers can use the whole day to explore a new framework, test a new pattern or learn about architecture. What’s important is that there is some sort of documentation afterward and that people pair up if they work on similar things. Innovation Friday is not mandatory. You can skip it and continue working on your product team if you want to.
Again - literally everything! People work on something they heard of at Code Brunch, some innovative front-end framework or something that helps them manage the tech stack. You can even bring up your idea for a product or improvement and test it! The results are often presented at Code Brunch, where others pick them up and extend them.
We did 24 Innovation Fridays in the past 2 years. People have already marked topics for the upcoming slots. While not everyone is always doing an Innovation Friday, roughly one-fourth of people use it for personal evolvement.
I think everyone knows what a Team meeting is - the particular case with us is that since we’re working in a matrix organization, it’s the only place developers can speak about technical issues in their project teams and connect to others with similar problems.
A lot about the progress in the multiple projects we have ongoing. People report structured by pains, successes, and learnings, which enables them to emphasize things depending on the current status. Sometimes it’s a technical issue, an issue with the business requirements, or just the success of killing a certain amount of technical debt.
We did a survey, and while some suggestions for an improvement of the agenda came in, the baseline was: keep it. It’s important to us! It’s also giving important input to me as a manager, so I know where and when to escalate things.
So that’s what our learning pipeline looks like:
Our learning cycle (gematik GmbH)
One question that immediately pops up is: how did you get there?
We started roughly 5 years ago with the Code Brunches - like real brown bag sessions between breakfast and lunch where people gathered every 2-3 week physically in a meeting room.
Normally, there would always be a new tool, conference experience or project to show. While sometimes people had to be pointed to a specific topic, most of the time the urge for sharing knowledge prevailed. Nobody was ever forced into that, everyone saw it as a give and take.
Over the time, the amount of potential topics grew and the topics themselves became bigger. So, the Code Brunches became a weekly thing.
After a while, the developers wanted to explore things deeper where they saw a potential benefit for their daily work. So we started the Innovation Fridays with support from our management board as an experiment for 3 months.
The feedback and outcome was overwhelming! People started to think about their work from a new angle. They completed online coourses that helped them understanding the context of their work. They wrote add-ons for analyzing merge request time, and so on.
If you think about establishing a learning culture in your organization, look at your assets first:
Start with simple formats, 30min - 1 hour per week can be enough for a start. Some speakers feel uncomfortable speaking in front of 40 or 60 people, split the audience into smaller groups on several dates to let the speaker gain experience. Collect feedback and outcomes, so you know where to improve.
So, what’s your blade?
Axel Schulz has worked in development and engineering management for 20 years. His focus topics include product design, developer experience, and tech leadership. Axel leads the Software Development unit at gematik since 2022. In his previous stations, Axel was the CTO of several healthcare companies. Axel lives with his family 500m behind Berlin city limits.