
Ask HN: Teamleads, Managers – How do you encourage learning? - muratk
How do you encourage other devs to learn? I&#x27;m interested in specific methods&#x2F;techniques&#x2F;things to try. In particular from the point of view of a team lead &#x2F; manager.<p>Background: My colleagues, many of which are junior, all appreciate learning, or more specifically &#x2F;having learnt&#x2F;. It&#x27;s a bit harder to get them to &#x2F;start&#x2F; the learning. There&#x27;s time, there is opportunity, and there are topics, but it oftentimes takes basically an assignment of a topic to a person. Once that&#x27;s there, everybody is learning, sharing, happy. What I&#x27;d like to improve here: I&#x27;d like to be out of the picture. Ideally, learning is a habit that doesn&#x27;t involve me. I believe (yes, it&#x27;s a belief) that regular learning is a powerful step in one&#x27;s personal and career development, and I&#x27;d like to pass that on to my team.<p>How do you do that? Please share ideas and experiences what to try or to experiment with.
======
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.

