How iPlayer use 10% time to turbo charge innovation?
The importance of autonomy in innovation
3 years ago we introduced 10% time to one of our teams in BBC iPlayer as an experiment.
The team has had full autonomy to spend every other Friday working on anything we want. Fast forward to now, this is a widespread practice across multiple teams in the department.
Initially it was a big ask especially as it’s hard to measure the success. So in this post, I want to share some of the principles that we took around our 10% time. Why it’s important? Some learning along the way. And share some successes we’ve had over time.
Why?
Our ability to Innovate is key to our future success.
Now innovation is a big word and it comes with many expectations. But innovation can be defined simply as a new idea, device or method. For us, innovation is about introducing positive changes to iPlayer, to the team, and to the individual.
However, bureaucracy kills innovation.
We want to create a safe space where everyone can freely express themselves. This includes playing with new technology, finding new ways of working, tackling problems as they see fit, and improving our own skills to tackle problems in creative new ways. We don’t mandate anything apart from sharing what you’ve learnt.
This doesn’t mean innovation is only allowed during the dedicated time. In fact, it’s the opposite. 10% time turbocharges innovation in the rest of the day job. It generates ideas and opportunities to inform our strategy and our work during the rest of the 90%. We have to make sure all the learnings and ideas are feedback to what we do day in day out.
We’re just recognising that sometimes creativity and innovation requires a different environment and 10% time for us is that different environment.
What does 10% Time mean for us?
We use every other Friday for 10% time. Engineers have full autonomy in deciding how they will spend their time. The fixed time helps to build a habit and makes clear this is a dedicated engineering time. It also helps ad-hoc cross-team collaboration too.
The types of things engineers do include but not limited to:
- Learning new tech/skill
- Hacks on new tech (AI/ML, to new frameworks, to serverless architecture, to IoT, to name a few)
- Prototype new product opportunity
- Improvements to tools, to process, to systems
- Crazy moonshot idea 🚀
- Develop specialist area such as audience research, security, perf, accessibility etc.
- Take the opportunity to work with people who aren’t in their day to day crew?
There’s no formal structure.
Engineers are free to decide how they’re going to spend their time. There is no approval. No forced collaboration. No forced innovation on a particular idea.
This is a lot of trust being put on the individual engineer. There’s no objective or goals being given by management to the individual on what should be worked on. Engineers are responsible and have complete ownership over the use of their time.
Don’t get me wrong. 10% time is still work time. It’s treated like a serious work day. It’s just that each engineer is empowered to make their own decision on how to spend this work time to make an impact on the product, to the team and improve themselves. We still expect everyone in the team to provide value back to the business. Just in this case, these are not pre-defined but truly bottom up values.
We’ve found that given the right context, autonomy and dedicated space, the right innovation naturally happen over time.
Rules
Although, engineers are free to decide what to work on. We still have some basic rules.
We ask the engineers to capture what they’ve worked on and demo it to the team.
The demo session is a great opportunity for us to get together and share what we’ve done which brings out further conversations and ideas. This is also a great forum for the team members to shine and gets recognition from peers.
We have a centralised log of what each team member has done since the introduction 3 years ago. This gives visibility to everyone in the team and a way for us to demonstrate business value. The extensive log gives us the opportunity to see trends and impacts over time. Of course, it also gave me the basis to tell a story about the usefulness of 10% time internally and to write about this now.
Learnings
Since we captured how 10% time is spent, we can spot trends with teams and gives a good indicator of the state of them.
For example, last year our Web teams were going through some exciting re-architecture to support us moving faster. Because we’re moving toward a new infrastructure, we saw a lot of the 10% time work focus on tooling and practice improvement. Once we had embedded a solid engineering environment, we started to see more product idea hacks in collaboration with other disciplines.
When we have a clear problem that the team want to fix, we saw engineers hacking on ideas that solve those problems in innovative ways. For example, one of the team goals is to migrate to a new tech stack as quickly as possible. One engineer came up with an idea to simplify the product user journey which improved our experience while making our tech architecture simpler. Because a quick hack was built, we could use that to validate the idea and it eventually became the solution we use on production.
However, there is waste too. Engineers could be solving the wrong problem or the same problem repeatedly. This does happen from time to time. This is where we need the encouragement of more cross-team cross-discipline communication. If multiple engineers in different teams are trying to solve a problem, then we need to spot and encourage them to tackle them together. This is where having a fixed time for 10% is very useful.
It’s tempting for management to get involve and try giving direction. But the reality is that each engineer will have their own unique interest, strengths, viewpoint and most importantly their own development plan. Based on this, each individual impact from 10% time can be very different. Any attempt to try to structure this time will limit our potential to get more creative output from the team.
For example, one of our engineers in the team is passionate about the craft of software engineering and created a self-paced learning course for rest of the team to follow. The course helped everyone in the team to get to the same level of technical understanding and standard super quick. However, it’s hard to measure the direct impact of work on product and it would have been hard to imagine this being scheduled as a normal piece of work. Once he has spent the time in 10% time and trialled it with the team, the true value became clear. We’ve not only improved the craft of the team but the quality of our code.
Success
Now you are probably wondering, what are the impact and value created from 10% time. It would be a quite a long list and would probably take even longer to explain the context of each. So I’ll select a few examples that highlight the range of innovations in the past 3 years.
Operational Innovation
There are many problems the team has tackled to make us more productive, efficient and operationally solid. These are things that might not directly improving our product/audience experience but they do improve our team’s operational capability in the long run which in turn creates opportunities for the product.
Docker based Sandbox environment for iPlayer
- We needed a quick and simple way to test variants of iPlayer in a production like environment. This is especially useful when we want to test out new ideas in user testing, especially when we want to use real data.
- So we created a highly customisable virtual environment using Docker where anyone in the team can easily startup, configure and use a branch of iPlayer. This has been part of our toolset for a while and would be hard to imagine not having it for developers, testers, UX and product team to test things out quickly.
Ops tooling improvements
- As iPlayer became more and more personalised, our traffic pattern to our systems was changing rapidly. So we had to invest in improving tooling in Ops from load tests tool, to monitoring setup, to alerting systems.
- Over time the team has used 10% time to research and spike new tech to find the solution that we wanted to focus energy on in 90% the time. For example, our connected TV team investigated using AWS CodeBuild for a more efficient pipeline and it’s now in production.
Capability Improvement
- One of the best uses of 10% time is playing with new technology and techniques. We learnt about Lambda, Kinesis, GraphQL to name a few quite early on in 10% before adopting them. This gave us confidence in selecting these solutions to solve business problems later on.
- Our Mobile engineers used 10% time to learn about Kotlin and Swift to bring functional programming to Android and iOS respectively. This has informed the team about the best way of adopting them in our codebase.
Product Innovation
As well as the above, we’ve direct product innovations that came out of 10% time too. Here are a few examples where engineers identify an opportunity to tackle a business problem or ways to improve iPlayer.
iBL Inspector — Product Tooling
- Our API team (iBL) is a representation of iPlayer business logic across-platforms and receives varieties of queries from our editorial and product colleagues. So the team built a web app that for our colleagues to understand and visualise the data with we’ve in our layer.
- Over time, we have introduced many additional features to this tool from ways to overlay popularity/trending data for the editorial team to give deeper insight into our programme metadata structure.
Rapid product enhancement
- When our engineers care about the product and the platform they work in, small or big opportunity will be spotted. Recently our Mobile team has shipped a few features for our users such as the usage of Adaptive icons on Android and launcher shortcuts on iOS from 10% time.
- Our web team also saw engineers shipping some performance enhancements making our site even faster following a web performance workshop which reduced page load time on episode page by ~15%. While making the site faster, we also made sure it’s always accessible with some pipeline improvement.
- In terms of making iPlayer more performant, it’s definitely harder for connected TV. iPlayer is supported in thousands of devices and the team created an automated memory usage monitor system to help us debug.
- The watch live experience for our live linear channel is another direct result a 10% time prototype. The prototype merged the previously separate live streaming page with our existing channel page. It not only streamlines the user journey and experience but greatly reduces the amount of code we’ve to maintain.
Moonshot — Credit Detection & ML
In early 2016, one of our engineers started studying Machine Learning (ML) was playing with Tensorflow in 10% time. Later on in the year, we had the perfect use case when iPlayer introduced Auto-play feature but we don’t always have end credit time for all programmes.
So the engineer used 10% time to trained a ML model to find out when the end credit starts and applied it on all iPlayer programmes. The initial prototype had 70% accuracy rate after a few 10% days.
The prototype showed us what is possible in a short amount of time. Coupled with the problem space. This is an opportunity too good to pass and it became a team objective the following quarter and turned into production service with improved accuracy and editorial tooling around it. We now have 90%+ accuracy rate for our top 500 episodes and saved hours of manual effort to set the timecode for end credit.
This is the first place where we’ve implemented ML powered feature in the iPlayer product. Since iPlayer is one of the biggest product in BBC, this has kicked started many conversations company-wide about how BBC can use Machine Learning to deliver value and initiatives to for the future.
Summary
10% time has been highly beneficial for individual engineers. It gives the space for engineers to grow, to learn, and to think outside the box.
These highly motivated engineers would then in return spot problem space and try to make the team better places to work, try to make the product just that little bit better, and most importantly generate opportunity for the future.
There still risk and improvement we could make. For example, we still need to find ways to encourage more cross-team/discipline collaborations. We still need to spot and incubate more big ideas.
As mention at the start, this started off as an experiment. Like any experiment, we need to keep iterating and improving it. This is what we’ve learnt in the past 3 years doing 10% time and I look forward to share we do in the future.
Join us
If you’re excited by the things we’re doing in 10% and you value dedicated time to learn and improve your craft in software engineering, then do get in touch as we’re always hiring. You can see all our job listings for BBC iPlayer here.
P.S. Written and published during 10% time 🚀
