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.

About “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.

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:

• The “all” page, which shows everything published today (or indeed on any particular date);
• The ability to create subsections freely, such as those for the US, religion, and things that have appeared in the papers;
• Keywording and keyword navigation;
• Contributor pages, such as those for Susan Tomes or Mark Lawson;
• Clippings;
• Alphabetical index pages; and
• RSS feeds all over the place.

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.

Summary

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.

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 http://www.guardian.co.uk/joinus. 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 techinterview.org, 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?

I’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.