麻豆约拍

Hi, I run the engineering team for 麻豆约拍 Digital's Radio Product Group. We build and maintain ; ; ; 麻豆约拍 Radio network homepages (,  etc.); ; the  and assorted systems and products that deliver online content related to the 麻豆约拍’s broadcast radio and music programming.

Part of our remit - and 麻豆约拍 Digital’s more broadly - is to pursue and deliver innovation in and around the products we release. To drive this objective, the engineering team in the Radio Product Group have been holding regular internal hackdays for a while now, at which developers along with editorial, product management, test and UX, conceive and work up new ideas around our products and ways of working.

What is a hackday and how do they work?

A hackday usually means a one or two day event where like-minded individuals come together to build new stuff. They often have a particular focus, theme or area of interest. When we decided to start running hackdays on a regular basis, we wanted to tap into the ‘event’ format, but didn't want to stifle anyone or arbitrarily limit the scope of what we could work on.

Consequently, we opted to alternate between themed hackdays and a looser format in which people work on whatever they were interested in. Themed hackdays might focus on a particular network (we’ve run a  themed hackday), brand (a  one) or a content type (one around live music events). Unlike many external events, we decided to limit our hackdays to within office hours - both for the sake of simplicity and to maximise the number of people who could realistically attend.

Location, location, location... 

At the time we started doing hackdays the team was based in , but we decided for a number of reasons to hold them in in W1 instead. It gave us the advantage of locating the team close to the majority of our editorial stakeholders and encouraging more involvement. It also got the development team away from their normal workspace and minimised the chances of them getting dragged back to business as usual tasks.

Since moving the team to W1 last year, we’ve held several events in the rarefied atmosphere of the Council Chamber, hacking under the watchful gaze of . Sessions usually begin with a short introduction at the start of the day, in which anyone with a particular idea they want to work on introduces it. Teams then form and presentations are held at the end of the day where the groups or individuals show and tell what they’ve worked on.

Responsibility for making things happen

Along the way we’ve learnt a few things. Fairly early on we decided that in order to keep the hackdays to a regular cadence, we needed to ensure someone was responsible for actually making them happen, and encouraging people to participate. As such, we established a small team of engineers who have taken on that responsibility: organising the days, involving editorial and getting everyone to go to the sessions. This has had the welcome side-benefit of giving them experience of tasks not normally part of their roles, and since we began doing the hackdays, several engineers have used that experience to help them transition into other disciplines.

Keeping the sessions fresh

In order to keep things fresh and engaging, the team hold regular sessions based loosely on Scrum retrospectives, to examine what’s been working, what’s not and how we can continuously improve on the format itself. As a result we’ve scaled back the themed events to make them less frequent, but hopefully more impactful. We’ve invited other 麻豆约拍 engineering teams to come and work with us on areas of mutual interest, and on occasion external companies with shared interests too.

Sharing success

We’ve also recognised the need to report on our successes outside of the presentations at the end of the actual hackdays. Many of the things that developers have worked on in these sessions have made it into the backlog for our products, and subsequently have been released onto live. For example, the ‘Tour’ feature in , which explained to new users how to use the product.

Others, like , became experimental products in their own right, in this case ending up on , where it’s feeding into our . We also have a fair number of hacks that have been turned into useful internal tools that make our day-to-day lives that little bit easier, that we would never have had the time or resource to develop otherwise.

A genuinely positive influence

Whilst it’s patently untrue to suggest our normal product backlogs are bereft of any kind of creative or innovative work, it’s also easy to feel when working on large projects that your personal creativity isn’t being tapped, or that there are new technologies you’ve heard of and are eager to utilise but don’t have the time. By giving our engineering team the space to think about issues, harness their ideas and learn new skills, our internal hackdays have had a genuinely positive influence on our products and provided a valuable benefit to the wider team.