An ABC of R2: E is for education tables

…which is one of the features central to the Eduction section. An example is this page of GCSE results.

Education tables are a great example of how one specialist requirement can reap rewards for so many others. We decided the Education section couldn’t be launched until we had created the ability to display and manage tables, and that’s one reason why we waited until August 2008 to launch it — there were a lot of other features to build before we got to tables.

Since launching tables for the Education section we’ve extended them for wider use. For example, they now feature more flexible formatting and the ability to click on a column for sorting. They’re also being used in other sections, such as in the Media section to display newspaper circulation, and the Football section to compare recent Spurs managers.

Journalism used to be about writing articles; these days it includes not just text, nor just audio and video, but also — as people like Adrian Holovaty and Jeff Jarvis have long said — managing and exposing data. This is one example of how that can happen.

An ABC of R2: D is for domain driven design

…which Mat Wall and I have written about extensively before, However, for this piece let me say this…

When you have a huge number of people for whom you are building software (1500 staff, 20 million unique users, and an entire wired economy influencing which way you should go next) then simply following instructions is insufficient, because your users’ demands will change and evolve over time — even if not during the current project then certainly before Version Two. So to minimise the cost of those changes you need to understand the way your users are thinking.

That’s where domain driven design (DDD) comes from. It’s about taking the concepts in your users’ heads and embedding them straight into the software you’re writing. And then when those concepts evolve and change the cost of changing your software is directly proportional to the mental shift that your users are making. When your users say “I want to make a small change” then usually it’s a small cost; if they propose a big change then they should understand when you walk them through all the implications.

For the R2 project we used DDD from the start, and it was key to many of our successes: when we discovered new opportunites which arose only from direct use of what we had implemented, then DDD allowed us to realise them.

Take, for example, the idea of “tone” — the principle that we should be able to categorise content by its “voice” or “style” (well, its tone). Its tone might be obituary, blog post, match report, and so on. The vague notion of this had been around since the start of the project, but we hadn’t settled on many details, let alone how to implement them. But after a few releases, and when the software started getting real use, it became apparent that applying a tone should be very like applying a keyword. Suddenly things fell into place. The functional requirements were clear, as were the implementation details. Tone has become a very powerful feature (here are all our obituraries, all our blog posts, all our match reports,…) yet it was a relatively straightforward piece of work because it was, in the end, a relatively intuitive idea.

Of course, domain driven design has a lot more to it than I’ve described here, and our use of it has been much deeper than feature implementation. If you’re lucky enough to be going to QCon San Francisco then today you can see our software architect Phil Wills presenting a lot more detail there.

An ABC of R2: C is for changing requirements

…which are a fact of life — certainly if your life revolves around developing software. During R2 there was a 40% churn on requirements. That means by the end of the project 40% of the work we had done had not appeared in our initial plan — some things were dumped, new things were introduced, and much was significantly altered.

The Agile way is to embrace change, and more than that it’s to structure your working practices around enabling and encouraging it. There are several ways we make this happen. One is to make sure that every task has tangible value to the end-user. Another is to prioritise the tasks so that the highest value work is delivered first. The second follows from the first: only if the tasks are individually valuable can they be arranged and rearranged.

One example of handling changing requirements is how we introduced keywords. We always believed these were important to our work, so we developed them very early — other elements of our plan were less certain and so might change, but we could safely defer such decisions until closer to the time we’d have to build them.

Managing keywords would require some slick tools if they were to be rolled out to more than a couple of staff. But our first cut was very primitive: it involved someone typing data into an Excel spreadsheet and then uploading that to a web page which would digest the spreadsheet and either process the data or report errors. It was not user-friendly. But this approach did have many virtues:

  • It was relatively quick to develop;
  • It was sufficient to enable just one person to manage the keywords, which was all that was needed then;
  • It allowed us to build further things based on keywords, such as a little component next to an article which listed the keywords associated with it;
  • It showed up real, unexpected problems arising from real-world use, that we would not have foreseen during planning;
  • It showed us what really was and wasn’t going to be important when we built a slick tool for wider use.

A 40% churn on requirements doesn’t mean there was a 40% budget overrun or time overrun, by the way. We came in on time and on budget. That’s another consequence of having working practices that embrace change rather than merely tolerate it.

An ABC of R2: B is for business analysis

…which means different things to different people. In our case it meant extracting requirements and turning them into something that could be implemented.

Business analysis is often misunderstood when it’s used in an Agile context. Agile people often think it’s not necessary — after all, they say, the analysis is best performed by the developers working closely with the customer as they go along. Many non-Agile people often think the analysis should be done up-front, written down, and then the workload on the business analysts (BAs) eases off as everyone else goes off to implement what they’ve written.

In fact business analysis was one of the most demanding jobs on R2. Analysis was indeed done up-front, at the start of the project, but only to a level sufficient to estimate the work, not to a level sufficient to implement it. Ahead of each fortnightly iteration the BAs would specify the forthcoming fortnight’s tasks in much greater detail, sufficient to be implemented. At the same time they would be dealing with queries about the iteration currently in flight. Thus at any one time they had to deal with work being planned and work being implemented.

In both cases they would be working with a very diverse group of people. For work being detailed the business analyst would take requirements from our business users and present them to the technologists for estimation; for work being implemented they would often take queries from the technologists and present them to the business users for guidance.

You could say the process of business analysis was often like being piggy in the middle, yet the personal skills of the individual business analysts (technical insight, strategic understanding, and not a little diplomacy) was key to the success of the project. The cohesiveness of — both from the outside and the inside — is in no small part due to the talents of our business analysts.

An ABC of R2: A is for article editor

…which is one of the first tools we built as part of the project. And it’s a lot more complex that most people expect, especially if their main exposure to a content management system is through blogging.

The main reason there’s so much to it is that there’s so much to the organisation it operates in. On a blog, if you write an article then you don’t need to worry about people finding it, because it will appear at the top of your homepage, which is more or less the only page that people will be watching if not the RSS feeds. Furthermore, a blog is really just a single stream of articles. So when you write a blog post you really only need to worry about the headline, the body text, and maybe an extract to entice people in — and you certainly don’t need to worry about the environment that the article appears in.

On a large website such as, by contrast, an article generally won’t appear on the homepage, and it has a less than 1% chance of appearing at the top of the homepage. But it will be linked from many other pages. It will also most likely be only one part of a whole mesh of other pieces of content, all touching on different aspects of that and much bigger stories (plural), so it’s important to link all these together. (This is part of what Lloyd Shepherd calls “slow news”.) Therefore the article editor has lots of boxes to fill in which ensure the article fits in properly with the rest of the site’s content. Keywords are central to link to and list it on appropriate subject pages; an alternative headline is essential to allow the article to be linked to from those subject pages and elsewhere (many newspaper headlines only make sense on the printed page with a particular layout and don’t translate to the web); a one- or two-sentence explainer is similarly important to go underneath the alternative headline.

And side from the importance of maximising cross-linking, there are other factors that explain the differences with an article editor for a blog post, but they are still all consequences of working in serious organisation. Rights issues mean the writer has to be identified exactly; design requirements will mean that different parts of the article (most obviously the standfirst) need to be separated so that they can be displayed differently; print publication times mean you’ll need to identify the print publication date and the web publication date separately; marketing decisions may mean you need to give a particular article a specific URL.

A while back, Martin Stabe lamented “Why can’t a newspaper CMS be as user-friendly as a blog?” I’m sure our article editor could be more user-friendly, but I doubt we’ll get it to be quite as user-friendly as many blog editors simply because it does a different and more complex job — a job in an organisation with hundreds of people and very sophisticated media and presentational requirements.

An ABC of R2: Introduction

In September 2008 officially finished the rebuilding of our website, which had started (depending how you count it) in October 2005. The project was known internally as R2. Over each of the next 26 working days I’ll be looking at one aspect of the project — one for each letter of the alphabet, for want of a better structure. Here’s what’s coming up:

Tomorrow I’ll start with A.

Obscure management phrases for real people: No. 3, Governance

This is the third and final installment of a series attempting to redeem words tarnished by management. Previously I looked at “strategic” and “leadership”. Today: governance.

This is a word that doesn’t tend to get used much among software development teams, and when it does it tends to carry the claustrophobic feel of heavy bureaucracy: ITIL, ISO, and lots and lots of very dull paperwork. But while it might not be thrill-a-minute stuff it’s something that the software team on the ground does need to be aware of: not just what it is, but how it works in your organisation.

Paperwork is not proportional to trustAbout governance

Governance is about providing the link between what people do in the software team and what people in senior management need and expect. Without that link there would be no mutual trust. That trust is important to the tech teams because, to be frank, none of us would be here without senior managers’ say-so. They provide the time and resources for us to do our jobs — not just the physical working environment and pay-cheques, but a meaningful and stable programme of work.

Here are a couple of examples.

Example 1: Life with poor governance

The importance of governance came home to me a few years ago when I worked on a project which involved a group of management execs somewhat separate from the development team. As with many such projects there were all sorts of unexpected problems, but we on the development team had the great benefit of working closely with the end users who who provided regular guidance and advice. As a result we developed something which more or less made those end users very happy — they didn’t get everything they wanted but they were happy that they got a good system within the bounds of budget and time.

The management execs, meanwhile, met regularly to track our budget, which was used responsibly and didn’t provide too many alerts.

Unfortunately when the final product was delivered the executive group was distinctly unhappy. It turns out they had expected one or two key features which the end users had decided they could cut among some of the compromises they had to make. When the development team and end users were proud of their finished work the executive group were disappointed.

The result was that future work with this group was incredibly difficult, because trust had been lost — they authorised future work only after a great deal of pain, and we generally had a work an awful lot harder to get anything done.

As result of poor governance the people on the ground had a much harder time in their day-to-day lives.

It’s clear to me that no one person or group was at fault here, but as a development team we could have done better. We should have flagged up not just budget changes but also changes in the evolving feature set.

Example 2: Governance on the

Good governance isn’t about reporting absolutely everything upwards, because you want your executive group to focus on the relevant issues.

On the recently completed rebuild project we were careful about what did and did not go to the board. For example, while the development team estimated and costed work in “ideal days” or “story points” we were careful to translate these into pounds sterling for the board. Ideal days is a useful abstraction for development estimation, but a pointless additional layer for a board.

In terms of the evolving feature set, change was tracked carefully within the development team and percolated upwards. But again, the information wasn’t conveyed verbatim, because development teams worked on lower-level tasks than were meaningful to users. So all lower-level task changes were translated into higher-level feature changes when presented to the board.

The result of this good governance was that when the the project ended both the board and the development team were united in recognising a job well done. We have further plans now, and although we’ll still have to justify each of them we are at least starting from a position of trust.

By the way, all this governance this did involve paperwork — in the form of writing board reports. But that’s only because paper is often a good vehicle for communication, and communication is central to building trust. We shouldn’t dismiss governance simply because it involves careful communication.

Governance in review

Good governance is therefore all about trust through communication; for software teams it means they get the trust and support of those senior people who shape their working environment and daily lives. Without good governance that trust won’t be forthcoming. Understanding how it works in your organisation means you have a route to ensuring you have senior management support when you need it.

Obscure management phrases for real people: No. 2, Leadership

This is the second in a short series of articles intended to restore the reputation of certain words — words that have been abused by managers and therefore have likely become meaningless to people who have to listen to them. Today: “leadership”.

“Leadership” is surely a word that needs saving from the management jargon-fest. It does mean something real and important, but I think it’s too easy to switch off when you hear it. It’s so loaded with portent that it’s easy to mistake the speaker as deluded or (at best) mistaken — after all, how many Winston Churchills, Nelson Mandelas or Martin Luther Kings can you expect to find in your organisation? Also, unless you recognise a revolution in progress, it’s hard to spot leadership at work.

Yet leadership is important and possible in even the smallest groups or organisations. As with the discussion of “strategic”, earlier, this article is part apology, part explanation.

Leadership in the animal kingdomAbout “leadership”

There is much that’s been written about leadership, but it tends to be for ambitious management-types [1, 2, 3], and therefore ignorable by the people who probably feel they’re doing the real work. Yet it’s important for everyone.

For me, leadership is about encouraging groups of people to being doing things they wouldn’t do if left to their own devices. These might be people inside or outside your team.

So if your team is stuck in a rut, then someone needs to exercise some leadership to help you out of it. Or perhaps there’s a dysfunctional relationship between your department and the rest of your company; again, it requires someone with some leadership to change the way people work together.

These situations are not just about implementing changes, they’re about changing the otherwise-routine behaviours of groups of people. And leadership doesn’t need to come only from those with the keys to the executive washroom. Here are some examples..

Example: Increasing the value of our product

This story comes from one of my former companies, and is about someone I’ll call “Mike”, because that was his name.

Our company produced shrink-wrapped software for search engine marketing, and its most common function was to produce search-engine-friendly content for sites which didn’t already have it. (An aside here: that kind of thing isn’t too respectable today, so let me assure you of three things: (1) this was a very long time ago, when the rules we know today weren’t written, (2) we always made sure our clients used the software for respectable purposes, and (3) the company today is quite a different beast and enjoys strong partnership relations with all the major search engines.) Mike was one of the technical consultants for the sales staff: he’d go along with them to sales meetings, answer technical questions, feed back ideas to the developers, configure installations, and so on.

The core module of the software was given manually-entered information about your company (company name, key product names, common related terms) and generated the content. This was a nice, simple sales proposition and was relatively easy to sell: we put you on search engines — simple, eh? However, we always felt it was undervalued, because it took a lot of time and effort to demonstrate and explain, and it was incredibly difficult to justify anything more than quite a low price on something as vague as “visibility”.

There was another module, too, which mined your company’s product database and drew out terms from that so you didn’t have to key them in yourself. If you’ve got 5,000 products and you were actually going to key them all in, that’s a real time-saver. But database connectivity was quite a new and and cumbersome thing (I told you this was a long time ago), difficult for the sales people to understand, and difficult to convince clients that they should spend time doing this when the only real value was to save you some typing which you probably weren’t going to do anyway. In the end our software was a technically advanced product of lowish-value and with a fancy database add-on.

But one day Mike started seeing things differently. He realised that by mining a product database the system was raising the profile of every single product that your company offered. Each of those products was a direct revenue stream for the company, and by raising the visibility of those products the system was going to put those products in front of more people, leading to a proportional rise is sales. Suddenly you could put numbers into a spreadsheet, and even a very conservative rise in sales would mean our system could be incredibly valuable to companies. We could comfortably value our software much more highly — as a proportion of your company’s annual turnover.

Mike went to our CEO with his new perspective, and our CEO was enthusiastic. He created a PowerPoint presentation, and took it round the sales people and his fellow technical consultants. It was clear to us that we had seriously misunderstood our own work. We had a new sense of excitement — we were sitting on something really valuable and hadn’t realised it. Nothing physical had changed, but we had a new outlook. We could explain what we did in a new and much more compelling way. We started using the phrase “return on investment” with conviction, and it actually meant something to our clients.

It wasn’t instantaneous, of course. Mike went out to trial our new outlook and our new presentations in front of clients. Lessons were learnt — the good and the bad — and were fed back to the team. Occasionally there was a confusion or misunderstanding, or subtle presentational tweaks needed to be made so as to make our message clear. Mike would ensure we kept learning the lessons from each other, and that our understanding was common and thorough.

I think the first actual sale of our software with this new perspective was ten times the previous average, and four or five times higher than anything we had sold before. And everyone was a winner: our clients had a tool to increase their revenue, and we were making more from our product.

Mike might have been one of the many people in the team, but he showed leadership. He changed the outlook and the behaviour of a large group of people. Nothing changed physically: we didn’t change our software, we didn’t change our staff. But we changed our attitude, we changed the way we talked about ourselves and our product, and we changed the benefits we offered our clients.

Oh yes, and we changed our revenue. That went up.

More leadership examples

There are numerous other examples of leadership that I’ve witnessed, but I fear writing about the protagonists as if they were saints, and I don’t want to embarrass them. So instead I’ll list a few examples only briefly…

  • The developer who lead the replacement of our proprietary application server, bringing in an open source (and much more managable) alternative. While everyone agreed it was important to do, he designed the architecture, sketched out the plan, and guided the other developers through the implementation. We still had a project manager and many others involved, and I can still say it was a team effort, but that developer saw it through from beginning to end and was a pivotal authority throughout.
  • The sales manager who led his disparate transatlantic sales people to be much more accountable and transparent about their prospective clients. He created a system of gates, in which the sales people needed to categorise their prospects, and ensured each member of the team shared their progress in a weekly conference call. With increased accountability, the sales team became much more trusted and respected throughout the organisation.
  • The team lead who helped us integrate a third-party Javascript product. He engineered an appropriate test framework, coached his team on its appropriate use, oversaw the development work, and volunteered himself as an out-of-hours technical point of contact in case of any problems. Something that was previously deemed risky and made people nervous was ultimately held up as example of how people might do things on future projects.
  • The business development manager who translated Agile planning techniques into his own (non-technical) department. He used these to regularly organise and prioritise a demand pipeline that was not only impossibly large, but was so diverse the various demands weren’t easily comparable. He ensured the various stakeholders discussed their needs together and came to a common agreement, allowing the department to regularly present a clear, consistent message to the rest of the business.

I can be quite certain that when these people did these things they didn’t for one second think they were demonstrating leadership. The sales manager will have thought he was just implementing good practice; the app-server developer will have thought he was just sorting out a long-standing problem. And in all cases they’d be right. But they demonstrated leadership, too.

Leadership in review

I’ve deliberately picked out people who were in the middle — not the top — of their respective organisations. The individual things they did towards each achievement ran over a sustained period, and were interspersed throughout their day-to-day jobs. But at the end of this they had changed the way their colleagues worked, and they were all undoubtedly better teams as a result.

So although leadership might sound overly-grand when referenced by management-types, it really can come from anywhere. I hope these examples show that leadership is a real and important quality, needed at all levels and in every organisation.

Obscure management phrases for real people: No. 1, Strategic

This is the first in a haphazard series which takes various management phrases and tries to ground them in reality. First, though, a bit about why I’m writing this.

A poor choice of words can be damaging. There are numerous times I’ve received an e-mail introduction from a company, and after a couple of paragraphs of impressive-sounding buzzwordology I’ve thought to myself “Yes, but what do you actually do?” Sometimes, though, some of those words actually translate into a tangible reality, and mean something for the lives of real people — even those who don’t spend their days thumping boardroom tables.

Sometimes, also, I find myself using management jargon in front of management-types, and then repeating it in front of non-management-types, which is probably not very helpful to the dialogue. But while these words may sound empty or obtuse, they do relate to things that impact on real people’s lives, and that’s why I use them.

So if I, or someone else, has used such jargon in front of you then please don’t shut down immediately. The consequences of these words affect our working day.

Today’s word is… strategic.

About “strategic”

I think the word strategic is more useful than the word strategy, because something can be strategic without you actually having a strategy. If a strategy is the route you want to go down, then strategic refers to the general direction you want to go in. You can know which direction you want to go in without knowing the specific route. More powerfully, you can know that something is the wrong direction to go in (not strategic) even if you don’t know the specifics of the route you should take (the strategy).

Here are two example of how strategic and non-strategic things affect our daily lives.

Example 1: Non-strategic work leads to expense and pain

This is an example where doing something that is not strategic would have meant making our business more expensive and difficult to run.

In June 2008 we launched a new-look Comment is free (Cif) on our Java platform with Pluck powering the community features. Previously is was running on Movable Type. Now let’s work backwards a bit… the site was launched in June 2008, so anyone can guess that work might have begun in, say, January. We’ll have needed to sort out some legal paperwork with Pluck, which you can imagine might have taken three months to negotiate, and before that a market survey and possible prototyping to assess the alternatives to Movable Type (let’s say two months’ work).

So in August 2007 we would have been at point where there was general acceptance that Movable Type was not the future platform for Cif, even though we didn’t have any certainty about its specific replacement. Movable Type was not strategic, even though we didn’t have a specific strategy, or at least not a very detailed one.

And at this point any significant feature development on our (now non-strategic) Movable Type would have had three kinds of cost implications:

  1. Its lifetime value would have been limited;
  2. It would have created more work for the people migrating to the new platform, because they would have had to migrate more features;
  3. It would have added more support costs to the Movable Type platform and hence the company.

This last one is probably most relevant to technical people, journalists and the production staff who work on Cif. Because “support costs” means not just “money” but “time and pain”. With the focus moving on to the next platform there will have been less and less expertise available to work on the limited-lifespan technology: there will have been fewer people available, and knowledge would be less fresh. Any technical work would be more time-consuming to put in place. It would also be less reliable because reliable work (rather than quick hacks) generally takes more time and more expertise; and yet this is a platform with less expertise and a known limited lifespan, so greater reliability is especially difficult.

Example 2: Strategic work gives you stuff for free

Meanwhile, what of all that so-called strategic work on the new platform? Why was that “strategic work” and not just “work”?

Because so much investment (translation: time and effort) had gone and would continue to go into the new platform there are suddenly lots of mutual benefits. Cif got lots of things for free, because they had been developed before for previous launches on the same platform. Some of the front-end features I can spot which came free include:

Similarly other sections have gained from Cif’s launch. When we later launched the Life & Style section I was particularly pleased to see the editor had written her introductory article on the new platform and opened up comments underneath it. Commenting was previously available only on our Movable Type blogs, but by building Cif on our strategic platform the Life & Style editor got more features than she might otherwise have had.


Sometimes management jargon really is jargon. But sometimes it translates into a tangible reality. Strategic things are about creating a better working life for us in the future, whether “better” means less costly, less frustrating, quicker, or more flexible. That should make it meaningful for all of us.

Buzzmachine goes clunk: When media companies do tech

Jeff Jarvis has a typically provocative post, saying that newspapers should outsource their technology. Lloyd has already responded saying that there’s more to journalism than news-gathering, and previous technological mistakes should not close the door on future successes. Here’s my response.

In this article:

The original position

Jeff’s position is part of his book-to-be on thinking like Google, which we assume is going to be called “What would Google do?” He’s taking many different aspects of the (traditional) commercial world and asking how organisations should reshape themselves in the light of Google’s success. A central theme is aggregation, and that a much greater, cheaper, more valuable whole can be found by uniting and organising many disparate smaller parts. Or to, reword James Carvill’s phrase for Bill Clinton, “it’s the network, stupid”.

In his latest post the proposal is that newspapers should push their technology into the cloud and focus on news. Actually, this is a bit odd, because I don’t know of a newspaper which doesn’t consider itself part of a media organisation, and Jeff would certainly say they should do so, so I’m going to refer to media organisations instead of newspapers. I think this is fair. Jeff kicks off with a discussion from Edward Roussel of the Telegraph, which one might mistake as a newspaper, but is more correctly seen as a multimedia operation within the Telegraph Media Group.

Much of Jeff’s argument, however, comes from Bob Wyman of Google, who says

Your IT infrastructure is a COST of doing business. It is not a thing of value.

Today’s newspapers invest in their web sites out of vanity and from an inability to get their heads out of the geographically defined markets of the past.

And when prompted by Jeff he says, yes, it would make a lot of sense for publishers to hand over the technology to Google. Jeff then sums up his own position like this:

So take the advice, papers: Get out of the manufacturing and distribution and technology businesses as soon as possible. Turn off the press. Outsource the computers. Outsource the copyediting to India or to the readers. Collaborate with the reporting public. And then ask what you really are.

So that’s the position. And here’s why I disagree…

Argument 1: You’re asking the wrong people

This is the flippant response I’ve already posted on Jeff’s blog. Since the question posed is “What would Google do?” Jeff naturally dropped a line to someone at Google, and guess what they said? They said “Let Google deal with it.” Amazing! What do think the response would have been if he’d called up a Microsoft executive? “Let Microsoft deal with it” perhaps?

So let’s take Bob Wyman’s opinion for what it is: an intelligent and thoughtful response from someone who has already made his choice about which company he wants to work for. Then we can take that opinion, and use it alongside many others (perhaps including Microsoft’s) and find a conclusion that we think appropriate.

Maybe we should even rephrase the question. It’s not a foregone conclusion that we all want to be like Google. Maybe the question should be “What should we do?”

Argument 2: How much do you want people to change?

Deploying standard technology in an organisation is often perfectly good, and pushing technology into the cloud is often useful. For example, Google Apps as an commercial office suite is going to be perfectly usable and very cost-effective for many organisations.

But sometimes that technology isn’t going to be quite right for your staff. Maybe they regularly need to read complex Word documents from clients which don’t import very well into Google Docs; maybe you need to change a few processes in your business to better fit the technology; maybe your staff need to stop whinging and be reminded who’s boss, dammit. What approach are you going to take? How much are you going to ask your people to change, and how much should the company (and its technology) change around the people?

This is part of the reason we have our own content management system at We could have bought one off the shelf — a lot of similar companies did: The Times, The Jewish Chronicle just this week, The Telegraph with its blogging platform, and so on. These organisations seem to have decided that their staff would learn to work in a new way, with new workflows and new concepts, all driven by what the technology offered. (I say “seem to” because I have no insider knowledge.) This is fine, and change is good for people, if not always comfortable. By contrast our technology development is driven a bit more from people than to people, and hence we have a content management system designed very much around the needs of our journalists, sales staff and others.

All that probably says something about the various organisations’ cultures. If what’s in the cloud or on the shelf suits the organisation and its people then that’s great; if not, then it’s not necessarily right to force your staff to change for the sake of technology.

Interlude: How to build a media company in the cloud

Before the final push here’s a scene-setting interlude…

Let’s consider Bob Wyman’s list of Google’s offerings, and just for fun let’s run with the idea for a bit:

Heck, an online paper isn’t much more than a complicated […] Google has search engines, alert systems, video serving, annotations, database services, AppEngine, more scalability than you can imagine, etc…. […] But, if Google doesn’t do this or, because of political issues can’t do it, then Yahoo! or Daylife or even the AP should do it instead.

So you’re just starting out in your media empire, you set yourself up on and start publishing. Then a while down the line you find you want to distinguish yourself and put a nice logo on your site. You find a graphic designer with Adobe Illustrator (that’s not really a techie skill) and they design a nice logo, and put it into your template because they know a bit of HTML and CSS (those are techie skills, but, hey, your 10 year old nephew can do that even if you can’t, so it’s not very techie).

Then you get an e-mail from an unhappy reader saying your site doesn’t render very well on Safari 3, and that’s a bit embarrassing. But now your graphic designer can’t help you, because they’re a graphic designer and they’ve reached the limit of their CSS skills. So you hire a professional web developer, and now that actually is techie, but at least they’re not a programmer…

…which is a shame really, because you’re suddenly finding you want to allow your readers to slice and dice some scandalous schools data, and you could make use of Google AppEngine if only you had someone with Python skills.

Some time later, in your now-bigger media group, you’re finding that for some months many of your services haven’t been performing terribly well and you’re losing traffic and reputation. After some pain, due to lack of in-house skills, you become aware that the problem is in the database. So at great expense you hire in a database performance expert who tells you that different databases need to all be tuned differently because they have different performance profiles, and Google’s own database services don’t offer the tuning you need for your particular setup. In fact, says the expert, the people who developed your current system had to write it in a really weird way just to get the performance they did, because they were constrained by the particular services that Google did and didn’t offer, so it’s now absolutely at the limit of its capability.

Never mind. You can always move it to Yahoo! or Daylife “or even the AP”. Obviously you’ll need to draft in a whole bunch of people. I’m afraid there will be some techies among them, and obviously none of the code in Google ports to any of the new services, so they’ll have to be rewritten; you’d have known that before you started all this, if only you had some technical staff of your own, but of course you didn’t because you’ve been concentrating on your core business. You’ll need some programmers, a project manager, and I suggest an architect, some quality assurance people and a couple of systems people, including a performance tester.

You might be wondering at this stage whether you can identify a suitably skilled group of people, and of course you would be able to do that if you’d built up a technical competence in-house.

You might also be wondering if moving to Yahoo! or Daylife “or even the AP” will leave you vulnerable once again to the limitations of their services. And well you might. And you might be wondering if your site will still end up looking like a hundred other blogs-with-knobs-on, or if you’ll ever achieve something like the New York Times, or El País, say. There is another option: to bring your technology much more under your control. It might not be right decision for some. But for you, it might be spot on.

Argument 3: Technical investment is inevitable

I hope that interlude shows that developing in-house technical capability is essential to any media organisation that is even fractionally ambitious. That capability will always include people, and sometimes it will include hardware or software. To make an up-front decision that your technical capability will never include hardware or software is pointlessly limiting.

You may argue that in the interlude above the media owner took a wrong turn. Perhaps they shouldn’t have introduced that schools data mash-up. Perhaps they were wrong to use Google’s database services in the way they did. Maybe they should have stopped before putting the company logo on their web page. But to argue any of those things is simply to argue that a media company shouldn’t be ambitious. It’s perfectly reasonable to argue that a media company can be too ambitious, but to set the bar at the same level for all such organisations regardless of their size, their history, or their people, must be a mistake.

On a more positive note…

Finally, let’s dispel the tone of opposition, because there’s one thing about Jeff’s argument I’m very happy about.

One of the central planks of Google’s success, and Jeff’s thesis, is harnessing the power of the network for mutual benefit. And Jeff doesn’t just talk the talk: he walks the walk, and he’s using the power of commenters to build the arguments in his book. (In one post he’s even quite explicitly soliciting input.) And that’s really great, because it’s all for mutual benefit. It’s advertisers who make Google’s services worthwhile, and Google shares that revenues with them, for mutual benefit. And because I know Jeff walks the walk I know he will share the success of his book with all those in the blogosphere who have built, tested and shaped it.

Jeff, I’m delighted to have contributed. I’ll be sending you my bank details momentarily.