An Engineer Looks at … Rumour

By Ian Alexander

 

Rumour is an interesting topic for an engineer, as at first sight it looks as if it has nothing whatever to do with the work of developing new systems and products. Engineering knowledge, says the man in the pub, is precise, clinical, definite. Project documents contain plain dry specifications and analyses. Projects proceed inexorably with ruthless single-minded efficiency towards their predestined goals. 

Only, they don’t. And rumour is alive and well in every company and organisation that I’ve ever seen, and seemingly in all the rest too. Rumour is person-to-person communication, only faster and more willingly accepted than anything that came out of Head Office or Personnel or Communications for that matter.

Management hates rumours, mainly because they are generally true, quick, and free of spin. Or, naturally, totally muddled and wrong half the time. Though when the rumour is that the boss has thrown a sickie the day after the bank holiday, and is taking it in Paris with his new secretary having fixed a meeting there on the Friday, it’s invariably totally unmuddled and right every time.

Rumour is, in other words, both too inaccurate and too truthful to be popular in official circles, which is why it isn’t about to die out any time soon. It’s as uncontrollable as the forces of nature. As with nicknames, the Powers That Be cannot control them, which is why even the strongest leaders like the Iron Duke and the Iron Lady had to be content with crisply memorable summaries of their characters in place of their given names. Mind you, Wellington’s nickname was actually given for the steel shutters over his elegant windows, to protect the glass from his unpopularity with the people of London, rather than being an allusion to his steely resolve with the French, but the fact is that nicknames and rumours tend to stick, even if some of the details aren’t exactly right.

The speed, penetration, and sticking-power of rumour are presumably a reflection of the trans-personal, or what Jungian psychoanalysts call the collective. Rumours circulate in the collective mind without effort or training. They start from nowhere in particular and travel at the speed of light, squared, trailing cosmic shock waves behind them as the laws of nature struggle to catch up with them.

Ordinary communications travel in ordinary terrestrial ways:  

Speech’s sound waves travel through the atmosphere at a few hundred metres a second, and in our noisy world, they generally only reach a few tens of metres at most. (Yodelling across a mountain valley isn’t speech, and I don’t care who claims it is a form of communication, it’s just a form of showing-off.)

Radio waves reflect off the ionosphere.

Rumours echo through the “blogosphere” and are propagated by other entities in cyberspace, the social networking gadgets. These strange virtual nightmares suddenly become comprehensible when you realize that they are nothing more than another way of sounding off: the Pub Bore finding a roomful of unknowing victims night after night. 

The Rumour Mill is, admittedly, affected by the prevailing climate of emotion, such as panic, overexcitement or even hysteria. Generally, though, it is a wonderfully rapid Bush Telegraph. It can cross time zones and “silo” boundaries between departments without effort. Compared to it, official newsletter and web channels are hopelessly slow, stiff, and out of date.

Rumour gleefully ignores all prohibitions on subject matter and political correctness. Company procedures are so dull because they are obliged to omit “unmentionable” topics like politics, class, sex, bribery, influence, skiving and all forms of naughtiness, ie everything that makes people tick. They also leave out everything that the procedure writer didn’t think to mention, whether because it was “too obvious” or because it was just part of the corporate culture and nobody noticed it.

Philosophers like Michael Polanyi call such things “tacit knowledge”, a wonderfully paradoxical name: for how can you know something you don’t know that you know? Wittgenstein’s delightful “You must keep silent about the things you can’t talk about” (it sounds far more musical in German: Wovon man nicht sprechen kann, därüber muss man schweigen) is clearly in the same vein.

I mentioned at the beginning that people assume that rumour has nothing to do with engineering. This is wrong because tacit knowledge, along with every kind of grist to the rumour mill such as politics and personalities, is crucially important in system development. The fact that it’s not nice doesn’t mean that you can ignore it. Of course, you may have to be rather careful how you write about it.

There is a famous and possibly even true story about a gadget called a TEA laser (it doesn’t matter what the letters T.E.A. stood for, but it was “Transverse Electrical discharge at Atmospheric pressure”). Anyway, the group developing the laser got the device working and claimed great things of it. Trouble was, nobody else except students who had worked at the group’s lab could follow their recipe, and people started to suspect they were faking their results. To defuse the situation, the team invited the sceptics to their lab to see for themselves. The device worked perfectly. It turned out that the recipe failed to mention that the leads connecting the working parts of the laser had to be less than a certain length, so that the signal could resonate quickly enough. Nobody had thought to measure the leads or to tell people how long they should be. It was just that everyone in the lab instinctively made the leads as short as possible, or just copied the ones on the working model on the bench. This sort of cultural transmission of knowledge is a part of every professional skill and trade. Indeed, sociologists apparently define “culture” as the set of unspoken assumptions shared by members of a group such as laser researchers or systems engineers.

The paradox of tacit knowledge – the knowledge that cannot speak its name, as it were – is especially acute in the largest and most careful kinds of system development. This is because contractors will only build what they are told to (and paid to), yet their customers don’t know what to tell them. Either they have to write down the obvious, which does feel rather like, um, stating the bleeding obvious, or they have to write down the stuff they don’t know they know, which could clearly be rather difficult. Why do they have to do this? Pay attention at the back! It’s because the contractors by definition share a different culture from the customer organisation. Software developers, for instance, know about hideous things like JavaScript and XML and Aspect-Oriented Programming. Their customers know about pretty things like telephones or clothes or music or cars or whatever their business is. Therefore, the assumptions made by the people who know all about telephones (or whatever) are absolutely different from those that the software people would make; and neither group realizes until too late why they are getting into such a muddle, because it’s all tacit. 

What is needed is for enough of the tacit knowledge to be surfaced to enable the essential requirements to be communicated across cultural barriers (such as contracts). This means serious work discovering the requirements, assumptions, technical terms and general understanding of the “domain” (telephones, the clothing trade, or what have you) so that the developers have a fighting chance of getting things right first time.

This is of course easier said than done. Happily, it means that the pompous company procedures – you know, the ones that go on about page layouts and documentation and minutes of meetings – are hopelessly inadequate in systems development. There are techniques that can deal effectively with tacit knowledge and unmentionable stuff like politics, but they aren’t found in official processes.

The first and most obvious is talking to people: not so much in stiff interviews, though even those can help.

Next, you can hold workshops explicitly to deal with assumptions, or definitions, or to tell stories (in my domain, we call them scenarios) about how a domain works. You’ll start to hear how people talk about their work. You’ll see some of the politics in action, and begin to know the personalities involved. That’ll explain a lot that didn’t make sense before. A colleague calls this “project sociology”.

Most boldly of all, you can be “apprenticed” to an expert practitioner, and you can learn a little of how they think and work. You may even hear a bit of gossip or a rumour or two. Before you know it you’ll have gone just a little bit native, which is why this is sometimes called “ethnography” or “fieldwork”. You’ll start to know what they know; or rather, you’ll start not knowing what you yourself know. Sound a bit like Donald Rumsfeld and his unknown unknowns? Well, guess what? Maybe Nixon’s “ruthless little bastard” was on to something after all.

(c) Ian Alexander 2007