Sugira o primeiro: crie uma solução central de hospedagem para qualquer coisa que os desenvolvedores pensem ser relevante para o aprendizado . No mínimo, vídeos de apresentações e bolsas marrons devem aparecer aqui; screencasts, vídeos de fluxo de trabalho etc. também são bons de se ter. Se alguém quiser escrever um documento de texto descrevendo como foi tomada uma decisão de design ou como eles acham que é um processo ótimo de revisão de código, deixe-o! Garanta que todas as contribuições sejam voluntárias. Date todos os materiais com clareza, para que os desenvolvedores possam julgar por si mesmos quão desatualizados eles podem (ou não). Isso pode ser tão simples quanto uma página de diretório no wiki interno (você possui um wiki interno, não é?) Ou tão complicado quanto uma solução do tipo StackOverflow que permite votação e comentários.
O que me mata - especialmente na grande corporação em que eu trabalhava, mas até na startup em que trabalho - é a quantidade de conhecimento gerado e perdido na organização. Essa estratégia ajuda a atenuar um pouco isso.
Sugestão da segunda: crie um calendário interno de eventos técnicos relevantes para a missão da empresa . Propague-o com o máximo de coisas possível (tudo, desde as reuniões do CocoaHeads / grupos de usuários até os painéis sobre desenvolvimento móvel para ...) e permita que os desenvolvedores adicionem os próprios eventos à medida que se deparam com eles. Pontos de bônus se a solução permitir que eles confiram e vejam quem mais está indo da empresa (o Google Calendar faz isso); ajuda a criar um senso de comunidade e ajuda os desenvolvedores a saber quem compartilha e pode discutir seus interesses.
Entre o que já foi dito - +9000 no envio de desenvolvedores para conferências . Também tenha um processo bem divulgado para que os desenvolvedores identifiquem o treinamento e digam: "Ei, você deve me enviar para isso!", Bem como expectativas claras sobre o que um desenvolvedor fará quando esse treinamento for aprovado (eles precisam compartilhar suas anotações para o resto da empresa - dão uma sacada sobre o que aprenderam etc.). Bons desenvolvedores geralmente sabem o que precisam aprender. Os grandes desenvolvedores geralmente sabem a maneira mais eficiente de aprender.