Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
In software development, technology is changing super fast. Therefore, learning new skills and testing new tools are indispensable . If the schedule is tight, developers will not have enough time to learn, then it will affect our company in the long run.
So my question is: should we allow developers to spend time at work every day to learn or test new tools? How many hours should be enough?
As a project manager, you want your team not only finishes within tight deadlines, but also develop. This is in fact a reasonable need that managers in general should think about.
My first advice is, like others have already comment: Don’t separate time to learn from time to work. Reason: Developers will see the “time to learn” as “time to do anything they want”, and that’s a waste of time. The best way is to create a learning & developing culture where everyone keep in mind that they must work and develop at the same time.
How to do it? There is no definitive answer for this, but I will share you real story of my company where I work as a PM. My company is 2 years old with less than 20 developers.
We don’t separate time to learn and time to work, but we encourage ones who learn and improve. We have a storage of “library” where developers can create and share their utility functions, slides, snippet of code, etc… all in one centralized place. They can register to be speaker at company’s restrospective meeting (We work in Agile/Scrum). So after the normal retrospective sections, we have 15-30 mins to discuss what our developers have learnt and will apply in their next tasks.
How do we encourage developers to do so? Simple, by incentive. During my time as a PM, I find out that it is very hard to create KPIs and assess developers’ performance. In our company, we use “learning attitude & result” as the most important KPI to assess our developers when thinking about bonuses and promotion. So in our retro meeting, the developers present new knowledge, and we rate their contribution from 1->5. The ones who contribute the most, and the ones whose contribution receives most rating, will surely have big bonus and promotion. So, in summary, instead of give them fixed time to learn, I ask them to show me their result of learning, and reward them for that.
There is no definite right and wrong about this method of assessment, but so far we are happy using our method. And we haven’t regretted it.
As usual, the answer is: it entirely depends on the context. Learning is not an on/off process, nor you can ensure proper learning in all conditions by allowing people to have, let's say, 1h a day of "learning time". This might be beneficial for some people under some contexts and completely useless for other people in a different context.
Topics are different, learning curves are different and, last but not least, people are different. I might be wrong here, but looks like the underlying problem is more related to the "tight schedule" which stifle any kind of proper learning process, and I'd rather address this problem than the learning issue if that's the situation. You'd better cure the disease rather than the symptom.
No, you shouldn't allow it. You should set an expectation and reinforce a culture where the continuous improvement (CI) is the norm. There is no magic hour split, but if people are spending 100% of their time trying to become more efficient at what they do (aka just doing short-term work) they will become less effective at their jobs over the long-term. Individuals and the company will not evolve without a strong CI mindset. If thats 80/20 or 60/40 or whatever, it depends a lot on the person, their experience level, and the day to day tradoffs of learning for the future or focusing today's effort on meeting short-term goals.
If you are trying to measure hours worked vs hours spent learning thats a separate problem. These activities often go hand and hand, and this form of measurement is often viewed as a form of appraisal that promotes negative behaviors from individual employees.
Stop measuring and start trying to build a culture where CI is the norm.
