We all work very hard, but the work we get often has tight deadlines, which never gives us a chance to try new tools (we're in web development). This means we never have time to try new approaches to a problem, or new tools, we're just cutting code together as quickly as we can from our current knowledge to get this job done ASAP.

While we have been told that we can use up to 4 hours a week on R&D, but in reality we never have enough time between jobs to make use of it.

Any ideas on how we could add in some space in tasks to allow for development.

  • 1
    Do you track your time? It's the only way to actually see what I have been doing, and to compare it against what I should have been doing. "Dang, another week where I only studied for 3 hours instead of 4!" Jun 4 '15 at 7:00
  • Related - workplace.stackexchange.com/q/11197/2322
    – enderland
    Jun 4 '15 at 16:03

There is only one way that you can make time for it. Make it a priority!

You need to place the appropriate value on the resource time. Block out a specific time each week that is spent only on research. Make this appointment something that cannot be touched.

There is always time to do the high priority things. If you don't treat it as a priority task, it will never happen.

  • 2
    At our company, we don't explicitly get 4 hours for research, but we have a goal to automate something every year. As far as I'm concerned, making it a priority is the only way to get it done. Blocking out time to work on it like you would with any other project is good advice. I make my automation goal do double duty and learn new tools and languages to accomplish the automation.
    – ColleenV
    Jun 4 '15 at 12:55

While we have been told that we can use up to 4 hours a week on R&D, but in reality we never have enough time between jobs to make use of it.

Any ideas on how we could add in some space in tasks to allow for development.

When I need to ensure time to get something done, I make an "appointment" with myself. That way, it's on my calendar for a specific time, and I won't plan any other work, or attend any other meetings during that timeframe.

The research doesn't really need to be "between jobs" - particularly if you a never ending stream of tight deadlines. Instead, find small spaces (1 hour, 2 hours) within your work week for researching.

Even the busiest of us have time for career growth if we make it a priority.

I tend to get in early each day and do a bit of research-type activity after I have read through and answered all my overnight emails and planned out the rest of the day. I also tend to eat at my desk often, and use that time to read and research. Others use time at the end of the day to try out new tools, read, and research.

You could also have a chat with your boss. Explain that you would like to research a particular tool or method, and talk about how it might benefit the group as a whole. Then ask if it could be considered a formal project, and if you could devote X hours per week to it. That way, you could more formally assign workweek hours to it.


I see similarities with my own situation. In fact I'm the lead developer and I also give opportunity for 4 hours a week to be spend on research.

As the lead developer it is my responsibility to justify that time. Luckily my boss is accepting about this strategic decision. Even though sometimes it's still a fight when other issues are more pressing. In the end when time is allowed to spend on research and you use it if no blocking issues exist, then do it and have your lead handle the justification.

An alternative when working agile is to make it a fixed item on the Sprint.


First, understand that 4 hours a week is a lot. That is 26 days a year. That's 5 weeks worth of time. You probably don't really need that much. So don't feel bad that you don't get to it every week.

Second, goals like "spend 4 hours a week on research" are really hard to meet. Instead, work on having goals that are crisper. For example "move to the new version of [tool we use] within [x weeks] of release" or "never be more than [x releases] behind the latest on [library we use]" are simpler to measure, and carry their benefit right in the goal statement so everyone knows why you might need to do that. You can also have "try one new tool or library every month" and other slightly more open goals.

Third, a goal ignored is time not spent. I presume you're doing something at least semi-agile so every two weeks or so there's some sort of meeting, either looking back over what's just been done or looking ahead and deciding what to do. As part of those meetings, you can checkpoint against the goals. What's been released or announced? Are you using the latest version? If not, who will be getting you there now? What tool or library is each person going to try this month? How did things go trying whatever you each tried last month?

These checkpoints that already exist may provide all the structure you need, but if not, you can add a Lunch-and-Learn or similar peer-to-peer presentation. For example, if Jo tries out the new library and it's just not ready at all, a 20 minute presentation showing how, despite the buzz and hype when it was announced, it has nothing to handle [something important to your team] will let everyone know they're not missing an opportunity by not moving to that library. Then if Sue has been experimenting with a new technique and getting great results, a 20 minute presentation to at least show off the results (and perhaps start to teach the technique) will encourage everyone to learn it. The usual bribe for the lunch-and-learn is that the company orders pizza or some other hot food.

If after 6 months of crisper goals, including these goals in planning and retrospective meetings, and holding peer-to-peer presentations, people are still not learning new things and you feel that you are missing some important innovations as a result, it will be time to spend money. Pluralsight subscriptions for everyone, and encourage them to use the offline viewers during their commutes. Start sending people to conferences - it punches a one-week hole in the schedule and ensures lots of opportunities to learn new things. Hire another person and lower everyone's billable hour target a little. The cost for these things should be justifiable by the gap between developer's knowledge and what they could have learned by now.


I honestly never manage to work at company that actually offer research time, All the knowledge I have today all is either from project I have work on, or when I doing my side project(closed not open).

The point is you can ask for some R&D time, but if your boss say no, you can always use your own free time, we are talking about your career here. The "I don't have time" is usually just excuse people use when they are way behind. It may be harsh but from my experience it usually are the case.

  • 2
    This may work on a personal level but I think OP wants to know how to achieve said research time as a team (e.g. with pronoun "we" instead of "I").
    – Brandin
    Jun 4 '15 at 7:38
  • @Brandin This is correct, we all work quite closely together and help each other out. I also do side projects in my own time, I just feel as a team we could be working allot more efficiently with the newer tools around.
    – Mint
    Jun 4 '15 at 21:21
  • 1
    @Mint personal knowledge can belong to a team, let say when you began to work on something and realize that you can do this thing with new tech/tool, and since you already have knowledge on said tool you can easily consult them with your team, and began answering all other question. I never understood why people separate team knowledge with personal knowledge both belong to each other. Team knowledge will became your knowledge while you can also offer your knowledge to your team.
    – kirie
    Jun 5 '15 at 2:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .