How Can I Help Foster A Culture of Continual Learning?

Over the past two years I've been learning and writing about .NET Core, which has lead to me starting a podcast all about it. But all of that learning has been in my own time. I'm incredibly lucky where I work, in that management have allowed me the time (during my day-to-day work time) to learn how to use things like docker, Azure, and other tools.

But I'm left wondering "how can I make sure that the knowledge and experience that I've collected can be spread amongst my work peers?" We already have a culture of lightning talks (which are informal, not-compulsory, and mostly "here is a thing that I have done/used"), pair programming, and wiki entries

So my question to you all is how would you want knowledge from a colleague to be shared with you? Brown-bag lunches? Lightning talks? Wiki entries?

I recently started at new employer and have been the beneficiary of co-workers who are more than willing to go above and beyond, to sit with me and answer question about what I'm trying to figure out as well as showing me tips and giving suggestions.
A big part of it is their positive attitude. I'm never left feeling inferior for having asked a question.
So I have committed myself to doing the same.
Happily helping anyone and encouraging them to ask me more.

I recently started at new employer and have been the beneficiary of co-workers who are more than willing to go above and beyond, to sit with me and answer question about what I'm trying to figure out as well as showing me tips and giving suggestions.
A big part of it is their positive attitude. I'm never left feeling inferior for having asked a question.

This is absolutely amazing, and I'm really glad that you have such fantastic colleagues.

I know that, early in my career, I found that colleagues who weren't willing to share tended to foster an environment of elitism and it really fuelled my impostor syndrome. "Clearly they'd be willing to help me out, if I was meant to be here!" and similar thoughts would repeat on a daily basis.

But it sounds like the culture surrounding your colleagues wouldn't allow for that to happen.

I really like the points that you raise, and they've made me stop to think about how different developers could implement them.

Everything that is persistent (recorded talks, articles/wikis). Some of the peers may be missing or not even hired.

We don't tend to record any internal talks that are given, but we do share slide decks and resources discussed.

Post mortems and incident reports I heard are awesome, but takes time to fill them, so the management has to agree on them.

I've only done post mortems in the form of personal blog posts for open source applications. But I like this idea, perhaps they could be included in sprint burndowns/retrospectives, as most of the issues that one solves can easily present for other teams.

I think it is important to understand that not everyone is interested in active continual learning. They might change strategies or learn something new if there is a demonstrated benefit, or in response to problems that arise. But in general, they are happier to keep the status quo. There's nothing intrinsically wrong with that, especially if their role fits these traits.

So my advice is to learn to recognize this distinction to save yourself some disappointment. For people who are continual learners, the format probably won't matter as much... they will be interested anyway! Personally, I am more inclined toward content (of any kind) that I can consume on my own time (docs, podcasts, videos) rather than scheduled events (lunches, demo meetings). But other people will have different prefs.

I think it is important to understand that not everyone is interested in active continual learning. They might change strategies or learn something new if there is a demonstrated benefit, or in response to problems that arise. But in general, they are happier to keep the status quo. There's nothing intrinsically wrong with that, especially if their role fits these traits.

This is the most important part, I think. And one which I hadn't even considered. II'll have to go back to the drawing board and re-think what I'd actually like to achieve, and how I could approach it with the thought that "not everyone will want to be involved," in mind.

I joined a team 10 months ago with a hope of learning a lot from the other devs who've been doing this a lot longer. But the work all happens in a very silo-ed manner, so the only team I get to see any output from anyone else in the team is during peer review, which usually needs to be done in a timeframe that doesn't facilitate learning.

In order to try and get at the knowledge in the other developers heads I've been trying to organize monthly lunches (sponsored by the boss) to discuss topics much like in your lightning talks. We're up to number 6 now and so far I've presented 4.5 of them, but at least people are still showing up!

In order to try and get at the knowledge in the other developers heads I've been trying to organize monthly lunches (sponsored by the boss) to discuss topics much like in your lightning talks. We're up to number 6 now and so far I've presented 4.5 of them, but at least people are still showing up!

This is fantastic! And it can be a great way of spreading experience of knowledge of a very specific thing.

I ran a lightning talk on the three major .NET IDEs recently (VS, VS Code and Rider), and I feel like it went down pretty well.

Grant Maki tells a story of how you can incrementally start trying something new with your team and that builds the culture of trying something new. It's okay to start learning something and throw it out quickly if it didn't work as well as it could for your projects.