• Culture
• Organise

Key lessons our agency has learnt from Eight years of Research and Development

A Quick History

Inspired by success stories from tech company greats, we started having regular research and development time in late 2014. We'd heard all of the tales of side projects growing into fully fledged products and teams thriving from being given the freedom to create things that interested them.

We started with Friday afternoons and speedily trialled various iterations to land on two days per month. However, five years later (2019), we had made five significant changes to our time, and we've continued making changes ever since. Those changes have been to both focus and format. You can read about those changes in two historic posts from 2017 and 2018.

One of the reasons that those changes have had to take place is that expectations can significantly vary on what R&D is for and what it should produce.

Differences of Opinion

I will not use this blog post to try to convince anyone of the importance of R&D time. I think I can safely assume you are on board with the idea if you're reading this. However, I want to acknowledge that research and development can be approached with very different goals.

People can have widely differing expectations about the expected outcomes of research and development, who owns it and who gets to decide what to do with it.

Within our context, we have different goals of what to do with the time we have set aside. These broadly fall into two buckets.

• Brightec Goals - which would be 'company' purposes for the time

• Individual Goals - which represent the objectives of individuals.

Some examples of these goals are:

If we are careful about balancing these goals, we can avoid ending up with unhelpful attitudes towards the time, which eventually will erode everyone's goals.

Aiming to balance these goals has led us to our current format.

Our Current Format

Timings: Monday and Tuesday on the last week of every month.

Format: Team activities in the morning of the first day, self-directed time after that.

The first day consists of some form of team activity. Often we choose to do a retrospective of the whole company since our last R&D, but sometimes we deliver training or give a presentation on a specific subject.

We then end that morning session with lunch and an opportunity to discuss everyone's plans for the rest of the time.

On the second day, we use our Daily Stand Up feed and format to share what we plan to focus on. It enables people to pair up where appropriate or get additional insights from the team to form their learning.

There are occasions when we deviate from this format. For example, we recently delivered two days of Agile training for the whole organisation during R&D, but these deviations are the exception rather than the norm.

The format works, but there are still challenges to overcome. Not least of which is coming up with what to do during the time.

A Little Facilitation is Needed

When we first started having R&D time, I assumed that giving people the time and space was what we provided and everything else would 'just happen'. Individuals would easily come up with new and exciting things to research. We, as a company, could be passive in our involvement and let it happen. That assumption was incorrect.

The reality is that it takes an incredible amount of discipline to regularly maintain a backlog of off-project items that could be focussed on for R&D. It's challenging enough to find items anyway as they need to be small enough to fit within 1.5 days. Most candidate items get quickly discounted as too large or too complex to pick up and put down over multiple consecutive R&Ds. Most people cannot sustain that amount of personal development rigour over the long term, especially when their focus is (and should be) on delivering for their clients.

We've found that the solution to this challenge is to create novelty. As a result, every time we have re-focussed or reformatted our R&D time, we have experienced a surge in activity, engagement and enjoyment.

As detailed in our previous blog posts, we have used several large 'rebrandings' of the time to re-focus our team. But we have also successfully utilised much more minor changes, such as:

• Timings

• Lunch options

• Meeting formats and activities

• Studio/furniture layouts

• 'Team' make-ups

Our key takeaway is that even the most diligent, disciplined individual still hits a point where they need a nudge and want to switch things up. Our job is to facilitate that happening.

Protection and Prioritisation

Some of the most significant issues we have faced with our Research and Development time have been when we have failed to prioritise it. I firmly believe that the quickest way to kill off momentum in R&D is for the leaders to set an example of not prioritising it.

There will always be the immediate pressures of client projects, but for R&D, we have to maintain a long-term view. And the only way to keep that view and ambition is to protect it.

The easiest way to protect the two days is to be diligent in communicating with our clients that people are unavailable and will be moving meetings. It's too easy to leave in a couple of meetings and immediately be drawn back into everyday work. Our experience is that people will often skip R&D altogether if there is a perceived lack of undisrupted usable time. So we must set an example and encourage everyone to do all they can to protect the time given.

Enough Time to Create

So far in this post, we have communicated thoughts on coming up with ideas and protecting our time. We now need to ascertain how much time is necessary.

As discussed in this post, we've gone from weekly half days to 2 full days per month. This was in response to trying to work out how much time is required to make progress in R&D and what frequency gives us the best outcomes.

We've landed on two days per month for a few reasons. First, more than one day is needed for our Software Engineers. They need enough time to set up a project before they can do anything interesting. Whether that's getting an environment working or setting up an API. If our Engineers only have one day available, they can quickly lose any hope of making reasonable progress.

Second, having it monthly means it is regular enough to remember what you did last time but sufficiently novel enough not to make it feel like it's 'day-to-day'. It also has the added benefit of marking the month's end.

Play Back

Although our Research and Development time runs well, one of our ongoing challenges is how to do a Show & Tell or Play Back session at the end.

Some form of exposing what people have been working on is essential. What would be the point of researching or developing anything if the knowledge couldn't be shared or no one saw it? But when and how to do that is challenging.

We'd struggle to do a whole team playback at the end of the second day because only some people have the same working hours, and, understandably, no one likes an end-of-day, all-hands meeting.

It's also become apparent that it's not appropriate for everyone to present what they've been working on or researching. Only some things done during R&D result in knowledge that needs to be shared or work that can be demoed. A Show & Tell should aim to share knowledge or show something interesting, not to check whether the time was used well.

“A Show & Tell should aim to share knowledge or show something interesting, not to check whether the time was used well.”

Our current solution to this issue is to use a slack bot that triggers during the afternoon of the second day and asks the following questions:

• What did you do for R&D?

• Do you have any links you'd like to include?

• Would you like to share this with the team?

We use an excellent little service called Standup & Prosper that handles asking everyone on the team the questions and then posts them back into our #general as a thread. We can then sift through those answers and pull out the ones best suited to share with the team. That allows us to schedule Show & Tell sessions for those people and the right audiences.

Key Takeaways

Hopefully, in this post, I've outlined the main challenges we've faced running R&D sessions and how we've looked to overcome them.

But to be as helpful as possible, the list below summarises our key takeaways.

• You have to facilitate - keeping R&D fresh and novel will always give the best return.

• You must balance the need for company and individual goals to get the best out of people.

• People need a good couple of days to feel they can 'get into' something properly.

• Prioritising the time is essential - dropping current work and doing what you can to protect the time.