Sharing Is Caring

Personally, it is very important to me to work in an environment where knowledge is shared and joint learning is encouraged. That's why I've been preaching over and over during the last months that a culture of learning needs to be established, how to get there and what it looks like in various companies. But what have I done for it myself? That's why I want to give you a glimpse behind our scenes.

I would like to point out how knowledge sharing began for us, what went wrong for which reasons, where we failed, and how we revived joint learning. A short story with ups, downs and a positive interim result of which we are proud of.

If you have knowledge, let others light their candles in it. Margaret Fuller

The Prologue

How It All Started

A couple of years ago a team at car2go started to add short presentations to their weeklies, given there was time. These talks — which didn't have a special name — were basically lightning talks. Like 'Brown Bag' or 'Munch & Learn' sessions, but without food. Nothing official, just a little icing on the cake.

I remember a few months later when I was writing my master thesis in Brighton, enjoying the evening at the beach and receiving a call from my former manager. We talked about various topics, including how Brandwatch lives knowledge sharing. Whether it's weekly lightning talks in Stuttgart, monthly tech townhalls or quarterly Engineering Summits in the HQ. To experience this and be a part of it was not only interesting but also very inspiring. That's how the idea of the tech townhall was born at car2go.

Following my studies and time at Brandwatch, I moved back to car2go (a.k.a. SHARE NOW) as Developer Advocate. Arriving there I noticed that the unofficial lightning talks became official. So there was half an hour a week for lightning talks, except once a month, when the one-hour tech townhall took place instead.

Well Thought, Badly Done

Great news but it still felt like riding with training wheels: the full potential had not yet been unleashed. Something caused friction. Talks took place only irregularly, whole sessions were canceled, and we had put a lot of effort into finding speakers. The talks were organised in a Jira Board, which was only accessible to an agile coach and me. It was exhausting and frustrating. I often wondered why nobody wants to participate. Later it turned out that we did stuff wrong. Or let's say, we didn't really think it through.

So, what were we wrong about? As already mentioned, we had two events. But how these differed from each other was not really clear to everyone. In the talks' length, topics, audience? To be honest, I still don't really know. Besides, the irregularity and the resulting mess did not create a kind of ritual; people didn't have it in their heads.

But things also went wrong in terms of content and form. People assumed that it would take too much time to prepare such a talk. In times of post-merger and product integration, there truly was no time. Even though we didn't officially consider the events for developers only, but rather as a technical event for the whole Product Creation department, audience and past talks still made that impression. Leaving the moderation to the speakers themselves and doing no more than searching twice a week for speakers led to the result described above. The idea was good though.

The Comeback

So, we noticed that things were not going well and that something had to be changed. Otherwise, it's more like a burden. Even though the responsibility was handed over to me in the course of this, the agile coaches have been still involved. At first, we pondered individually and later we discussed our ideas. We've come up with a rough plan which I would like to outline in the following.

Tech Townhall

As mentioned at the beginning, we had introduced the monthly tech townhall but never really got its purpose. At Brandwatch this was pretty clear. Lightning talks took a maximum of seven minutes and, if I recall correctly, two minutes for questions. It was also very localised and not necessarily limited to tech. The tech townhall was completely independent of that: cross-location, the talks took at least half an hour and thus were more in-depth. So, I entered the dialogue with the agile coaches convinced to define the delimitation in this way. The others, however, argued that we'd better focus on one event and make it flourish before we go multi-track. It seemed entirely reasonable to me. Since we saw more potential in the lightning talks, especially for the beginning, we stuck with it and officially fused it with the tech townhall. A single event series was created and communicated in an initial lightning talk.

Redefining

The task was to redefine the remaining event series which covers form, content, and purpose. Even though the lightning talks have been established as a knowledge sharing event, there are some other intentions as well. It's about sharing passions or something being proud of, getting to know colleagues better and presenting more confidently in front of people. In order to get there, we clarified that although it should be related to our business and our jobs in its entirety, it should not be exclusively and by no means only technically. We want to have the whole department represented, as well as personal passions. For example, we have a colleague who runs a brewery in his Brazilian home. I'd love to learn more about it, as it makes it clear once again that we are more than our job.

At the same time, the event needed to evolve and become more diverse. We defined the lightning talks with a maximum of ten minutes plus another five for questions. In addition, we have also tried out a number of other formats: book reviews, open discussions, conference talk summaries or deep dives into single topics. To make it even more diverse, we have some other ideas in mind. Be it roundups of clean code principles, discussing together exciting talks, virtual barcamps or inviting external guests. I still hope to have Marcus Poehls (futurestud.io) or one of the hapipal contributors joining us. We want to embody an open mindset and be open to new external stimuli.

Most importantly, we don't want anyone to feel forced to put a lot of work into preparing the slides. The rule of thumb: preparation time less than or equal to the session's length. This seems to be doing great so far.

Transparency First

To be open not only means to take but also to give. The first step was to open the event to the whole company; anyone who is interested is warmly invited. For example, a marketing product manager joins us occasionally. The event is accessible to everyone in the employee app's calendar with a reference to a tiny website, which gathers all links and information in one place and is easy to reach anytime and anywhere.

The last point that should not be underestimated is the organising. It is an event by employees for employees, so why not let them be part? Again, I was inspired by Brandwatch, so we replaced the closed Jira Board with an open Google doc. Everyone has the opportunity to see all past and future talks, as well as reserve a slot wherever they like. Even if one cannot participate, this is no problem at all because all recordings and slides are available online and are linked in the said document. It's lovely to see how different colleagues are working on the document and the backlog is constantly growing.

Microsite gathering all links in one place

Conclusion

Lightning talks almost evolved overnight in a version that is adopted and valued. Since this August there has only been one week without talks due to sickness. Now, about eight weeks later, we have already scheduled talks for the next three weeks. But that’s not all. We have less and deep technical talks as well as humorous topics; almost the entire range of topics that we cover with our teams. Even across multiple locations. I wouldn't say it's a ritual yet, but it's in people's mind. Even if the name may no longer entirely fit, everyone knows about it.

I’m incredibly grateful for all the contributions from attendees and agile coaches. It is a joint success and will surely not be the last. I’m proud of us and my colleagues should be as well. I had not thought that such a fast change is possible. Let’s take joint learning to the next level and spread it beyond departmental boundaries.

Occasionally, one has to take a step back and view the big picture in order to recharge energy and sense mistakes.

The story's moral: many things don't work at the first try, but it's worth it to keep trying, iterate and check the results. Failure is no shame as long as lessons are learned. What problems have you struggled with, how have you solved them and do you even have any tips?

Cheers,
Felix