Category: General management

Never mind Google, this is for you

Even the greatest ideas aren't readily applicableMy public service for today is that of matchmaker, and specifically finding a match for the many online commentators who have a start-up-shaped solution for newspapers’ current crisis of faith and future.

Over on Mashable, Vadim Lavrusik has a useful round-up of “12 things newspapers should do to survive”. It’s good to see a lot of thinking brought together, and nice that the Guardian’s last Hack Day was noted with approval. But if there’s one thing that rankles me it’s the seemingly glib assertion that newspaper companies should emulate Internet start-ups, and which features at number six on Vadim’s list. He says that “creating a startup-like environment that encourages innovation in the newsroom” is one way forward, and cites three sources.

First, start-up veteran Scott Porad on the problem:

Over an 8 year period, my last startup grew from a startup into a corporate environment with several hundred employees and layers of management.  For the last 5 or 6 years of that I felt like we spent 80% of our time planning and only 20% of our time doing stuff. […] On the other hand, my current startup is the opposite — we probably spend 5% of our time planning and 95% doing.

Then Mike Briggs on how a newsroom can generate some start-up-like energy. And finally Ryan Sholin of Publish2, who thinks that you should “Make your newspaper function like a start-up.”

Somehow start-ups seem to be the panacea: not only do they make good stories, but it’s so easy to spot the successful ones: for instance Google started in a garage, and Microsoft was started by just a couple of people. And let’s not forget the many, many start-ups from more recent times. You probably remember Kevin Rose’s, which was successfully bought by Six Apart, which loved it to death; or, which was so successful at making URLs short, they’ve practically made them vanish. And let’s not forget the current media darling, Twitter, which is generating so much profit they’ve run out of positive numbers to express it and have had to start using negative ones. Meg Pickard has a more complete and up-to-date history for those of us with selective memory.

But that’s not to say there’s nothing there; a typical start-up has the kind of drive and energy in its half dozen employees that any corporate CEO would love to have reproduced across their 1,000-plus workforce. I’ve written before on about injecting start-up goodness into the newsroom, so you can go there for that. Mark Briggs does acknowledge all that is easier said than done.

Instead of me explaining why, let me introduce the start-up standard-bearers to the new blog from Simon Waldman. This extract from his first entry is worth quoting at length. Although his examples are older, rather than new, internet companies the principle is the same, being about “the general ways of the online world”:

It has always struck me that there has been a huge amount written about Google, Amazon, Wikipedia and eBay and the general ways of the online world. Some of this is brilliant, and genuinely insightful, some of it is frothy digital euphoria.

There has also been plenty written about what is wrong with newspapers, broadcasters, Britannica, record labels etc, and what they should or could have done; but there have been very few books that I’ve come across that take a systematic look at the what has happened to these businesses – and what they have done that has actually worked, often in the most trying of circumstances.

The point is – businesses that have to deal with the internet are fundamentally different to those that are the products of it. It is great to look at Google; great to admire Amazon, and Wikipedia is as fascinating a social and creative phenomena as you fan find. But if you are running a business that is profoundly structurally challenged, you share very little of their corporate DNA.

Yes, everyone needs to know about their world, but thinking you can just graft on the bits you like from them in a hope that you will ‘get digital’ is no more likely to succeed than putting on a flashing bow tie and hoping everyone thinks you have a sense of humour.

Simon is writing a book for the rest of us, who need to listen to those with ideas about how to save our challenged industry, and who also have the responsibility, along with our colleagues, to actually do the saving. The blog is the online counterpart to that book, which will be called Creative Disruption. As you can see from the extract above, it’s less “What would Google do?” and more “Never mind Google, this is for you.”

In ten or twenty years we’ll be able to look back and see which ideas from who were the wisest. For now I’m going to be a paying a lot of attention to anyone who recognises the fundamental DNA difference that Simon describes, and who deals with it.

How news organisations can harness startup-power

These are some thoughts on how news organisations (and specifically those which have a background as newspaper companies) might create new opportunities for themselves. In particular I want to focus on why and how those opportunities might come from outside the organisations themselves.

The thinking behind this piece has sprung from two articles: the first is by David Carr, in the New York Times, in which he seeks an iTunes-like saviour for the news industry, and the second is Jemima Kiss’s thought-provoking response on

What I’m going to present isn’t new, by the way — it’s about being open and encouraging innovation. But what I do hope to add to conversation is the idea that we don’t have to have all the answers ourselves, and that we can — and should — encourage others to work with us. I’m also adding some practical actions to take.

Here’s the structure of what follows:

Background reading

David Carr’s article in the New York Times is headlined “Let’s invent an iTunes for news” but that’s rather misleading. He’s actually calling for a way to charge for news content, pointing out that Apple has done this very effectively through the iTunes Store (although he never uses that phrase — he conflates iTunes, the desktop software launched in 2001, with the iTunes Store, the online shop launched two years later and accessed via that iTunes software). He does refer to one or two gadgets which could be an iPod for news (“Now all we need is a business model”), but the underlying point of the article is that content needs to be charged for one way or another.

Jemima Kiss picks up on the gadgets theme and dispenses with it quite quickly — “I think newspapers are wrong to put too much effort into pursuing degradable devices with a very limited potential audience.” Instead she says news organisations can find salvation within, and urges them to “start thinking like startups”.

Both David and Jemima refer to the “newspaper” industry, which is understandable but puts us in a limiting mindset. The companies they are referring to have gone to great lengths to diversify themselves into other media (most notably various digital media) with some genuine successes and we should embrace that. I’m going to refer to it as the news industry, although that’s arguably too broad. We’re all referring to the same thing: the-industry-which-used-to-be-the-newspaper-industry-but-now-reaches-across-many-media-including-paper industry.

A brief look at the music and news industries

The music and news industries do have similarities, which is why David has compared them, Jemima has followed, and others have done so, too. Both are facing declining sales, and many people in each industry hold the rise of the internet as partly or wholly to blame. In both cases their core product is content, and they are both facing the atomisation of this product — from albums to tracks, and from newspapers to articles — as the internet becomes more ubiquitous.

But they differ in the way they have faced the growth of digital media.

Figures from the RIAA show the US music industry in near-consistent decline since 1999, after years of near-consistent growth before. This 1999 point is more-or-less when digital music took off and sharing became easier on the web. The music industry tried to lock down its customers’ new-found freedoms, but unsuccessfully. Only when the iTunes Store arrived did some kind of calm prevail.

In the news industry DMGT’s annual report of 2007 shows a steady decline in UK circulation since 1994/5. From the US the Pew Research Center shows a steady decline in total sales of daily newspapers going back to 1990. In both cases the charts don’t go back further. But unlike the music industry we cannot blame this on the rise of the internet. These downturns started before what-was-then-newspaper content was widely available digitally.

So the music industry might point to the internet as the source of its troubles, but for the news industry the internet was just something that was going on at the same time. Furthermore each industry has met the challenge of the internet differently: the music industry has tried hard to prevent copying of its content, while the news industry has made some efforts in that direction, but has largely let its content go in the hope of rewards elsewhere.

As a consequence the music industry has an uneasy relationship with the internet, and still finds it difficult to get on there. By contrast, in the internet the news industry has another means to market, one in which it hasn’t made enemies. The internet could be the source of the innovation and upturn that it needs.

So if this innovation is to be found, where might the news industry look?

Why not look internally?

Why can’t news organisations look internally to find a revitalisation for their business models? Well, of course they can, and should, and do. Looking internally and externally for new opportunities are not mutually exclusive, and to not look internally would be a dereliction of duty. That’s why most commercial companies have a a special team dedicated to this — Business Development — aside from the responsibility of each of its employees every day to push the organisation forward.

But seeking solutions internally won’t maximise its dose of innovation. That’s because people inside organistions are most likely to see opportunities through the prism of their work in the organisation: we people who work in large organisations spend 8, 10, 12 hours of every day in these places, and the problems we’re driven to solve are generally those that relate to our daily work, and the particular people and processes we encounter there. Even the Business Development team is tasked with creating innovative opportunities that fit in with the company’s known strengths and current structure, and what it can practically achieve today — radical ideas beyond this are going to be difficult to handle. In general a company will value people who make the company better; it will not be very interested in people who have a great idea that does not easily fit with what it does.

Additionally, I think the rallying cry of “think like a startup” — as positive as it is — is particularly difficult to act on in a large organisation. That’s primarily because large organisations attract people who want to work in large organisations. They are subeditors who thrive on subediting and don’t want to have to produce business models; they are A&R people who love nurturing new bands and don’t want to sell sponsorship deals; they are marketing people who love planning marketing campaigns and don’t want to negotiate office leasing. They are not generally people who thrive on doing it all themselves, which is the driving force of a startup founder. They are people who thrive on achieving wonderful things by being a specialised part of a much greater whole.

Finally, business success stories are themselves unusual, so casting a net into the internal talent pool of one particular company is unnecessarily limiting. By all means we should look to home to find a success story, but we shouldn’t only do that.

To repeat, none of this is to say that innovation cannot be found internally, but we shouldn’t seek it there exclusively.

Let’s briefly compare internal and external success stories…

An example of an internally-generated idea

Jemima uses the example of the technology blog as an internally-generated idea, so let’s look at that in more detail.

The site describes itself as “the online extension of the prestigious D: All Things Digital conference” which started in 2003. Its “creators and executive producers” Walt Mossberg and Kara Swisher drove that for four years before launching the blog in April 2007 — or rather, before being able to launch the blog in April 2007, because the site is under the umbrella of the Wall Street Journal.

In ordinary circumstances such move would have been detrimental to WSJ since seems to be taking support and infrastructure from the bigger organisation whenever it wants, and yet retaining independence (on stories, production processes and technologies) when the ways of WSJ don’t suit it. WSJ would only have allowed this if there was some clear upside for itself, and of course it’s the conference, which we can readily expect to be a real moneyspinner. Walt and Kara spent four years proving they had a viable revenue stream before they got the support to expand into their own independent blog.

The conference-extended-into-a-website is an internally-generated line of business from WSJ and its parent, Dow Jones, and conference organisation is very much part of their daily business. Dow Jones organises quite a lot of conferences throughout any one year — on finance, economics, and environmental issues among others — and therefore will have a dedicated team of conference organisers to bring each one together. Guardian News & Media has a similar line of business.

None of this is to talk down the conference or the website, which are beacons in the tech industry. But it is an attempt to show their lineage as an outcome of Dow Jones’ daily operational machinery, and the key revenue-generating part of that machinery (conference organisation) is a well-established part of the company. The conference and website will be highly valued by Dow Jones and WSJ, and the kind of business unit that any company would be grateful for. But I suspect that if this kind of business unit was going to be the key innovation that reversed the news industry’s fortunes then we would have discovered that by now.

Now let’s take a look at…

An example of an externally-generated idea

David looks to the iTunes Store as an example of an industry saviour, so let’s consider that.

The iTunes Store revolutionised and arguably saved — or at least slowed the death of — the music industry, yet it was an innovation that came from Steve Jobs, a man outside the industry. It came at a time when music sales were first declining and it’s not as if the industry didn’t have its own ideas to deal with the rise of digital music — but those internally-generated ideas turned out to be quite misjudged.

The iTunes Store gave consumers more freedom over their ownship and use of music. It was never likely to come from inside the industry because, as David pointedly says, “Mr. Jobs saw music as […] an ancillary software business to generate sales of the iPods and iPhones. That’s not a perspective that flattered people in the music business”. We can readily imagine what reaction might have been received by a hapless music company executive if they’d have originally suggested the idea to their boss.

It took an outsider to devise the most workable innovation.

How to harness startup-power

Individual news organisations will continue to discover and exploit profitable seams from within their own structures. But they also need to be able to identify and exploit innovation from outside.

(By the way, I’ve called external innovation “startup-power” in the title here and above mostly in an attempt to be eye-catching. However it does largely capture the idea, and it does chime usefully with Jemima’s call to arms, so it’s not entirely superficial.)

For a long time the music industry tried to fight consumers’ desire to have more freedom with their digital music, and it did this by trying to create new business models entirely on its own terms. It only started successfully getting to grips with digital music when an outsider entered the game, and that outsider is taking a pretty healthy cut of the revenue. The music industry might have been able to dictate better terms if it had more to bring to the table earlier.

The news industry needs to put itself in a better position than the music industry did. I’d say there are three steps which will enable this to happen.

  1. Create opportunities for external innovators;
  2. Recognise and make contact with those innovators when they come along;
  3. Be in a position to best exploit the innovations.

Those are pretty obvious, but they still need careful consideration, because there’s still room to handle them poorly. Let’s take a look…

Harnessing innovation 1: Create opportunities

Creating opportunities for innovators means presenting what you do in multiple ways of accessibility. For news organisations the obvious example is RSS, which in some sense is less consumer-friendly than nicely designed web pages, but makes the raw material (articles) more accessible, and hence provides more opportunities to anyone else building their digital venture.

But large news organisations tend to provide only summaries in RSS, which parallels music companies’ early paranoia of digital music piracy and prevents external innovation. This puts the content out there, but only a bit — the news organisation is still holding it tight to its chest, still not trusting anyone external, and not giving anyone else the chance to innovate.

RSS is not the only means to create opportunities. The New York Times has released a number of APIs which are simply yet more raw materials for external innovators. Their terms of use prevent commercial use without prior agreement, which means that anyone can experiment and those who have a commercial proposition can work out an agreement with the Times.

Finally, let’s not think that content is the only thing news organisations do. They also provide advertising services (so there’s scope to open that, too) and much else besides. Perhaps everything an organisation does has scope for opening itself up to innovation if just enough imagination is applied.

Harnessing innovation 2: Talk to the innovators

Recognising and making contact with the innovators is a fairly obvious next step, but it’s rather different in the online world from the offline world. Experimentation is easier with digital assets than with physical ones: it can happen anywhere in the world, and due to the way digital media can be copied and distributed it can happen largely without the originator knowing.

Allowing the use of one’s assets or services without the knowledge of the originating organisation might seem daunting, and akin to giving away the assets or services. An obvious action would be to allow registration ahead of use, which means a channel of dialogue is opened immediately. The Times has used this approach with its APIs. But that option has its drawbacks, mainly that it creates a barrier to entry. Given that a small proportion of experiments will lead to something useful there’s a strong argument to remove that barrier, however small it may be, so as to maximise successes.

The alternative to enforcing dialogue is to make it so enticing that innovators will want to enter into it voluntarily. This means creating a forum or other environment that is sufficiently useful for innovators to make the active choice to speak to you. And it also means making yourself available in other ways — at other people’s conferences, seminars, and so on.

The dialogue of course has another direct benefit, which is that you get to understand how people really are innovating with what you offer. It provides you with an opportunity to change and improve what you offer so as to generate more opportunities for more innovators.

Harnessing innovation 3: Exploit innovation

In theory the third step is trivial — after creating the opportunities and speaking to the people who are using them it should be easy for both parties to get to a win-win on making something of lasting value.

However, when it comes to a large news organisation interacting with a very small organisation, such as a startup, the large organisation can easily act far too slowly. It will have committees and contracts and steering groups to go through. But startups worry about cashflow and have sufficiently few staff to be able to deploy them quickly if other opportunities present themselves in the interim. If the large news organisation cannot become fleet of foot then it stands to miss those opportunties as the innovators lose patience and pursue other interests.

This can be a difficult culture change for large organisations. Unfortunately it’s rarely possible to know just how valuable a lost opportunity might otherwise have been. But if a large company were to consistently fail to exploit external innovation then it might be a death by a thousand cuts.

Wrapping up

News organisations already have internal mechanisms to create and exploit ideas so I’ve spent some time trying to set out why internal innovation shouldn’t be considered to the exclusion of external innovation, and outlined a little of how external innovation might be developed.

I think this idea of developing external innovation might be particular to the digital times we live in, and not just because many might think we’re running out of our own ideas. Instead I think it’s a consequence our newly-networked world, where so much data and services are readily available globally, and so many ideas can be tried and discarded in such a short space of time. Previously the limitations of geography and physical objects meant businesses had to focus almost entirely on exploiting known opportunities for themselves. But in a digital world it’s easier than ever to create opportunities for others, and the rewards of creating those opportunties for external innovators is more immediate.

That historical economic perspective, however, is something that others would be better placed to evaluate. For now, those of us in news organisations probably need to focus on the more immediate concern of making innovation happen. Looking externally for ideas is not about waiting for someone to come by on a white horse and presenting a road to a happy ending; it’s not about hoping we get lucky. It’s up to us — we make our own luck.

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.

Interview tips for that tricky developer-pharmacist role

We’ve launched a big campaign today to expand the Guardian Unlimited technical team even further — software, systems, project management, and more. You can see the online ad at I won’t tell you that the reason you should seriously think about joining us that GU is packed full of friendly, intelligent and dedicated people. But I will tell you one small thing about how I’ll be conducting those of the interviews that I’ll be in.

The GU software team is a little different to many others. Like most teams our developers spend a lot of time understanding requirements, sketching out solutions, implementing, bug fixing, and so on. But unlike many teams our developers don’t spend any time at all surveying petrol stations, weighing pills, or being held in weird prisons run by pathological prison governors.

I’m sure that news will surprise a lot of people, because I know a vast number of developers are very focused daily on the old petrol station/pharmacy/solitary confinement side of software. And I know this because these are the questions they get asked in interviews.

I once attended an interview for a role where I was asked the pill-weighing question, set out on, for example:

[…] the queen gives the assassin 12 pills which are all completely identical in shape, smell, texture, size, except 1 pill has a different weight. the queen gives the man a balance and tells him that all the pills are deadly poison except for the pill of a different weight. the assassin can make three weighings and then must swallow the pill of his choice. if he lives, he will be sent back to the bad king’s kingdom. if he dies, well, thats what you get for being an assassin.

only one pill is not poison and it is the pill which has a different weight. the assassin does not know if it weighs more or less than the other pills. how can he save his skin?

I was able to answer the question only because I’d read it the previous month. Fortunately they decided to change the job spec and withdrew the role, and I was spared a working life of having to deal with royal assassins. Or brainteasers. I hope no-one’s going to tell me this wasn’t what the job was about, though. After all, what else could the interviewer have been trying to learn about me?

Petrol pump PCI’ve also met someone who likes to ask potential candidates “how many petrol stations are there in London?” I was keen to know why he asked this, since I was pretty sure he didn’t work in a company that audited petrol stations. “I want to know if they’re a good problem-solver,” he replied.

Here’s my tip for testing problem-solving skills: make the problem as realistic as you can.

Interviewing is a difficult and artificial thing. I’m sure I’m not the world’s best interviewer, but I do know that honesty and transparency are important, because without that you and the candidate can’t make the right assessment of each other. So when it comes to creating scenarios you’ll find out an awful lot more if you make the scenario as close as possible to what really happens in the job.

If you think your team members spend important time solving problems it’s a good idea to take a moment to consider some situations where that skill was important. And if you can’t think of any, then maybe problem-solving isn’t such an important skill after all.

Here are some problems I can think of right now that we’ve faced recently:

  • A really important person in the business wants something done really quickly, but they’re so important they don’t have time to explain it properly to you.
  • We need to get a particular data feed into a particular system. What are our options? And which should we choose?
  • A particular piece of code keeps throwing up far too many bugs than is reasonable. Why might that be? And what should we do about it?
  • We need to change a bit of code, but it was build 5 years ago by someone who’s no longer here. Where do you start?
  • We want to add a new feature somewhere, and although it seems like a naturally intuitive extension it’s actually disproportionately difficult to do — what’s gone wrong there?

No pills, no prisoners, no petrol stations, no foxes crossing rivers with geese. There are issues with using these situations, of course. We’d need to make a bit of an effort to work them into something that’s solvable in the confines of an interview situation. And I don’t get to show off some kind of pseudo-cleverness in front of the candidate. But I’d say both the interviewer and the candidate get much more out of the ensuing discussion. Because it does involve a discussion, not a simple one-way answer; we don’t force people to solve problems in isolation.

And one more thing about life here at GU. We do an awful lot of Java programming, so it’s not usually terribly useful for us to test someone’s use of pointers, either.

But if you do want to use pointers — or weigh pills — then it seems there are plenty of other opportunities for you.