HN Explorer

Ask HN: Teamleads, Managers – How do you encourage learning?

1 points by muratk ↗ HN
How do you encourage other devs to learn? I'm interested in specific methods/techniques/things to try. In particular from the point of view of a team lead / manager.

Background: My colleagues, many of which are junior, all appreciate learning, or more specifically /having learnt/. It's a bit harder to get them to /start/ the learning. There's time, there is opportunity, and there are topics, but it oftentimes takes basically an assignment of a topic to a person. Once that's there, everybody is learning, sharing, happy. What I'd like to improve here: I'd like to be out of the picture. Ideally, learning is a habit that doesn't involve me. I believe (yes, it's a belief) that regular learning is a powerful step in one's personal and career development, and I'd like to pass that on to my team.

How do you do that? Please share ideas and experiences what to try or to experiment with.

2 comments

[ 5.8 ms ] story [ 21.3 ms ] thread
usernamebias
I work with a small (12) group of developers for a certain startup. I'm been the longest at the company, so i supposed you can call me lead. The title rotates from project to project. Gives everyone the change to lead the team. Some of them are Senior developers, some are fresh out college or just recently bootcamps. Things that have had significant results in the wisdom and effort throughput are responsibility, teamwork and repetition. I'll expand.

Responsibility - Often times entry-level jobs start out by slowly intruding material until a certain level of knowledge is gain. Not with us. You're going to hit the ground running. Day one you will clone the repo and start hacking at it. You will be expected to complete a set of amount of features/bugs or whatever. How? Google it. This is not left without supervision and guidance of course. All work is peer-reviewed and collaborated on. We even share tips on how to be a stack overflow power user. Countless times a junior dev has left Seniors saying, "Damn, I should have thought of that". I truly believe that stress is a great potion for extra XP. Heck, some of my best work has been done under a deadline induced panic.

Teamwork - I find it extremely valuable to handle business critical jobs as if it was a tag team wrestling. I was skeptical when I first heard this. Thinking that a single developer would be more efficient if he focus on one thing and did it right. But boy was I ignorant of the alternative. Here is an example. Feature B has to done by certain day, size and complexity of the feature is arbitrary. Rather than assign to a single dev, its broken up into chunks, and spread out. This allows for fantastic teamwork, albeit a lot of technical fights about the best methodologies and such, but this is as healthy as it gets.

Repetition - This important. No matter the material it will not be learned first or second time around. Its only through countless trials and errors that I and the team really understand something. Example. Laravel, a fantastic PHP framework. When we began using it, we built 6 mock applications, 4 of which where the same thing just built differently before everyone felt hella comfortable using it. And like magic, the thing we were actually supposed to build with Laravel was done 40% faster than projected. and a lot better too.

muratk
This is fun advice for team building (not in the let's-drink-a-beer sense, but in the forging-effective-work-teams sense). And it's great for learning what you need at the job — I am wondering how to get people to learn the other stuff. Looking at that new library, trying out a language feature they don't need (but maybe they might have), experimenting with our processes, challenging old habits, … none of it directly helps with the task at hand, but will be invaluable over time nevertheless.