|
|
|
|
|
by Ididntdothis
2327 days ago
|
|
“For me, it was probably starting holding regular tech book review sessions.” How did you do these so people actually participated? My company is very deadline driven so people don’t really care about learning. Every attempt at regular learning meetings quickly died because people feel they don’t have time. Do you have a specific format? I have led regular meetings about coding style in another company. These went pretty well but in the current company I have failed at instilling curiosity for learning things for its own sake |
|
I had to convince both sides: 1. the management so that they would give us explicit permission to take time from our "actual work" time 2. the devs to actually start and keep it going
management caved in after... - I researched our competitors and their tech, highlighted features which would be very hard/impossible to implement given our architecture and what we needed to learn - dozens of comments about what we lose implementing feature Y in the "old" and "known" way vs using tech/service X - made comparisons to different professions which always have to stay on top of their game to win
all while repeating the message that we cannot have a world-class product without a world-class tech team. I think framing this as a "loss" instead of "gain" helped a ton.
With management buy-in, we were creating a "learning" card for everyone in the tech team each sprint. These cards were "committed" so there was no getting around of finishing them.
The dev team needed some motivation as well. Coding features as quickly as possible has obvious and visible advantage - you get praised, you might get a bonus, you might be promoted. Learning on the other hand.. less so.
To keep a long story short, I convinced them that the more they know the better their market value is by showing various stats. After the initial nudge, it was just intellectual curiosity that kept the meetings going.
Format wasn't anything special: - pick a book/article/system by vote - one person spends a couple of hours going through the chosen 'thing' - prepares a list of items to talk about - people vote about what should we talk about (before the meeting) - we have a presentation/discussion. each meeting ends with - list of practises/ideas we would like to implement. the list is committed to our documentation repository and followed up on - list of things we would like to learn in the future