Yet another ex-staff tuppence on the BBC's new media restructure

Last week Tom Coates wrote a pretty damning appraisal of what he thinks of how the BBC's proposed restructure will impact on new media at the Corporation, particularly on what, up until now, he called "an environment where parallel parts of the BBC could operate independently". There was a central new media team, and then each content producing department had their own new media teams (many of which had originally been staffed with central new media editorial people who had been 'devolved' to the divisions in an earlier restructure during Greg Dyke's tenure as Director-General). Naturally what caught my particular eye was Tom's claim that:

certain parts of the organisation with a kind of critical mass of smart and clued-up people could really thrive and generate their own culture and goals and get things done

...

not all parts of the organisation were similarly dynamic, despite the often amazing number of talented people working within them - specifically, in my opinion, Central New Media

I found it interesting because having been one of the people working in the central department during the time Tom was at the BBC, I often felt it was precisely because of the independent operation of the very talented parallel parts of the new media family (like Radio & Music and News) that the job of the central team was made increasingly harder and harder.

Firstly, it gave the bosses in the content producing divisions a bigger stick with which to beat my project teams - "My three software engineers have launched this, this and this in the last four weeks - what on earth are you spending my budget on centrally, your projects always take months?"

Secondly, they helped to exacerbate the demand for new features from around the rest of the BBC. Every time Radio & Music or Factual & Learning or BBC Scotland came up with a new gizmo that wowed people inside or outside the BBC, everybody wanted to use it. Naturally the local team didn't want to scale it or develop it into a pan-BBC product or service and then support it. After all, that was what central New Media was for, so it would be added to the number of projects the central team were working on, or the number of pieces of software they operationally supported.

Thirdly, having these little catherine wheels of bright sparks flying all around the business meant that local divisional pride, achievement and recognition was based on what had been done locally for the division concerned, rather than what contribution had been made to projects that helped the BBC's new media teams as a whole, leading to an us/them culture. That meant, in my 'us' view about 'them', that to the detriment of some of the bigger central projects, the people with planet-sized brains in the outlying new media areas were not always thoroughly engaged with projects that were being built centrally, but which had been instigated at the request of their division.

In the end of course, much of the comparison that Tom makes between the different products launched by the departments is that between some very pert tasty little nectarines and some very unsexy ugly pumpkins. The new media teams within the content producing divisions were often free to produce focussed small-scope agile quick wins because the central new media team were engaged with the kind of long term infrastructural heavy lifting that doesn't win prizes or make headlines.

One of the projects I inherited a couple of years back was email delivery for BBC News - delivering email faster and more reliably than the commercial company that BBC News had been using, and doing it with just three Linux boxes rather than a huge server farm. Nobody noticed much when we switched over to the in-house system, but since it launched it has probably saved BBC News hundreds of thousands of pounds, which will have been re-invested in either journalism or other new media services, all with no public fanfare. And central new media in the BBC was littered with these kind of projects, acting more as a central software writing clearing house for the corporation, rather than a publishing house that could do great innovative fun new online things with their editorial proposition.

Apart from the different relative scopes of projects, the primary issue that the local development teams within the content producing divisions of the BBC didn't generally have to deal with was balancing out the requirements for software across the BBC as a whole.

One of the proposed features for the voting application my team was building was the ability to share votes. It was a requirement from BBC Sport and Radio Five Live that votes about football could be posted on the sport site, the 606 site and the Five Live site and the results would aggregate the audience across all three. The solution was simple - all recently published votes were listed on one page in the admin system, and if you wanted to include someone else's vote on your page you clicked on the question and got the HTML snippet you needed to embed in your page. Easy.

Until the implications of this functionality was realised by producers from a different BBC radio network. They were infuriated, and adamant that they only wanted their listeners and their audience voting on their votes.

They were both equally important internal 'clients' from the same division with the BBC - so what to do?

Insist that the functionality remained, and have an executive from one network on the phone saying "we are paying for you to build us a pan-BBC system, and since it doesn't meet our requirements, our producers won't use it, what are you doing?". Or remove the feature, and have executives from Sport and Five Live on the phone saying "we are paying for you to build us a pan-BBC system, and now it doesn't include the functionality we agreed upon that we need for our site, our producers can't use it, what are you doing?".

Or come up with a compromise to the system that added a layer of complexity to the application, which of course made everybody happy - except all the other executives from around the rest of the BBC who were then on my phone asking me why I've just put my project milestones back by another three weeks whilst we build this extra functionality for Radio into the next development sprint.

In his post Tom also cites backstage.bbc.co.uk as a central new media initiative that has been a disappointment, because the API into the BBC isn't as rich as the example he chooses, Flickr. I would argue that a lot of that is more to do with the culture and lack of structured data within the content producing divisions of the BBC, than any unwillingness or inability on the part of the central new media teams to open up that content. In fact virtually the only content central new media produces is the homepage - and the Homepage Archive is the only backstage prototype that has so far made it on to the bbc.co.uk servers as a 'BBC service in beta'.

Using voting again as an example, one proposed feature for the benefit of the 'API' into the BBC's content was an RSS stream of every vote published on the BBC site. It met with editorial objection after editorial objection from the content producing divisions - what if it is just a draft test vote, what if the vote has been published but the URL is not being linked to until some tv/radio transmission related announcement, what if a sensitive vote has to be removed from the site by not including it on any pages any more but isn't actually deleted from the system by the editorial team by mistake. In the end, faced with the choice of adding another check-box to the voting admin user interface ("Is this vote OK to be published by RSS?") and another layer of publishing complexity, we de-scoped it from the project - hence no promised voting feed for Backstage.

With the content production teams often isolated from their new media teams, the divisional new media teams isolated from the central team, and radio and TV commissioners seemingly completely isolated from new media as a whole, I think the old structure made these kind of situations inevitable.

You could never blame "TV people" and "Radio people" for not grasping the new media nettle. Some of them joined the BBC before they had to have any dealing with new media. Some of them joined since, but their primary interest will have been the TV/Radio side with little time for the 'new media' components of their job. And I don't think they are helped by the way technology has become more invisible to them.

Ten years ago if you were in an edit suite putting a programme together and your source material was on DigiBeta (or whatever they were using 10 years ago), you needed a DigiBeta machine to play it in. And if you wanted to add something from someone's home movie that was only available on an old Betamax copy, you needed to get Television Centre's one remaining working Betamax machine wheeled over to your edit suite. And if you needed some archive footage that was held at Windmill Lane on 2" film reels, you knew you needed to get a librarian to pull it off the shelf, get it transferred over to the format du jour, and then have it biked across London for you. All of those steps have visual, physical and locational clues to a producer about how difficult and expensive they are to carry out.

However, once you are in a digital environment, there isn't much to inform the lay-producer about what the difference is between playing in some video held on their local PC, or from the PC three desks along, or from a PC in another building, or from an archive server in the BBC's building in Windmill Lane. Or wherever the material is stored anywhere in the world by anyone. Whereas, as a new media person I am already thinking about networking, maximum bandwidth availability, and building in back-up capacity.

Equally it isn't therefore obvious to BBC production staff what makes some feature requests for software or web applications more difficult and expensive than others to develop - and I don't think the old structure did much in the way of helping them to understand that, or managing their expectations. Especially when neat little things done locally happened very quickly and looked great, whilst long term infrastructure projects trundled along unloved by the people who had requested them in the first place.

I like eyedropper's grandfather/father/teenager take on the BBC's tri-media family. I'd hope that the restructure will be beneficial for all the different parts of the wider BBC, but it would be great if it at least got all of the new media people sitting down on the same sofa for a family chat more often.