When I was a dev lead I came up with the concept called a "learning spike," where a developer would pick a focused topic to dive into for a set period of time[1] and then do a short[2] presentation of learnings to the entire team. This would be backed by an official story in Jira or whatnot. The goal would be for the developer to choose something that sparked their interest (within the loose boundaries that it be at least marginally related to the team's work.)
I figured this would be great in a number of ways -- developer deepens their knowledge of some topic, possibly even has fun, practices their communication skills by sharing with others, and the entire team learns something. Although the idea was technically backed by management, it didn't really catch on. I think the problem was that the short term opportunity costs were too high when everything was on fire (which was often).
“I think the problem was that the short term opportunity costs were too high when everything was on fire (which was often).”
That’s such a sad way of thinking but pretty common. In addition a lot of people seem to be thinking that if not everything is on fire all the time they are moving too slowly.
I found that a sustainable pace with short bursts of fire make for the fastest progress.
Fires keep you on edge, show you what’s actually important, and help trim fat. But without long period of calm in between, I can’t consolidate what I’ve learned, nor build upon that wealth.
I figured this would be great in a number of ways -- developer deepens their knowledge of some topic, possibly even has fun, practices their communication skills by sharing with others, and the entire team learns something. Although the idea was technically backed by management, it didn't really catch on. I think the problem was that the short term opportunity costs were too high when everything was on fire (which was often).
[1] 2-3 days max, probably.
[2] "Short" is the key word here.