Some years ago, at an “all hands” meeting at a company where I worked, the head of the company enthused at length about Jack Welch’s famous ruthlessness. At the time I said to various people that if I wanted to work for General Electric then I knew where to find them. I wasn’t joking: GE have an office in easy walking distance of my house. However, I never set foot in there until last night, when I attended a talk by Richard Berry—part of their series of “agile talks”.
The talk was about management and leadership, and the differences in management style (command-and-control vs. facilitation) and the importance of different personality types in how teams work. Management theory, then. (And yes, there were flip-charts, and a 2×2 matrix, and book recommendations at the end.)
I’ve seen some disappointment expressed about the content of the talk. Surely this is all rather old hat: no-one now believes that command-and-control is a sensible way to organize a software development team. I’d have two responses to that, the first of which is that overt command-and-control may be rare but that the common alternative—insisting that people “take ownership” without giving them any meaningful control isn’t really the same thing as facilitation.
My other response would be that even if the broad outline of Richard’s talk didn’t hold any surprises, it’s possible to do this sort of thing badly or well, and Richard did it well. The last presentation I saw that covered this rough area was given by some ex-marketing guy who seemed to speak largely in clichés taken from trashy pop psychology books (“don’t sweat the small stuff”, “change is the only constant”, etc.). Regardless of the big picture being peddled, there were telling little details in Richard’s talk that, for me, showed that he knew what he was talking about. This wasn’t an occasion for buzzword bingo.
Richard has an interesting background. He’s an anthropologist by training, but has for many years worked helping large organizations companies such as GE and Microsoft; and also other sorts of organization, such as the ILO. (At some point I really ought to say more about the concept of corporate anthropology. This, along with Kevin Simler’s essay on start-up cultures, and the Heideggerian approach to market research at ReD Associates make for some interesting data points.)
The central idea of the talk was of managers as facilitators: the word “facilitating” literally meaning “making easy”. This ideal is described by Dick Gabriel in his Patterns of Software: Tales from the Software Community thus (p. 129):
A manager should be like the sweeper in curling: The sweeper runs ahead of the stone and sweeps away debris from the path of the stone so that the progress of the stone will be smooth and undisturbed
However, the talk didn’t simply slate command-and-control mentalities as being worthless relics from a bygone era. For me this was one of the telling details: being generous in the appraisal of ideas being criticized. The upside of command-and-control leadership is the lack of ambiguity involved. In life-and-death situations, a confused chain of command is the last thing you need. Even in software development things can get rather, er, interesting in a team where authority is unclear (e.g. in a situation where, going by the org chart, project technical lead is outranked by one of his team members).
One of the topics that got discussed was the notion of being an expert (an SME, in the Knowledge Management jargon) vs. being a learner. Here the claim was that a learner was always expecting to learn new things, and so would embrace change, and not shy away from admitting ignorance and asking questions; whereas an expert would find things that they didn’t know about as a threat.
This was something that I found unconvincing, or rather I thought it was mixing up two distinct concerns.
I’ve lived in Cambridge most of my life, and I know some of the dynamics of expertise both in industry and academia, and I don’t think that genuine experts are threatened by the thought of the limits of their expertise becoming known. Of course, you get people who like the role of being an expert, and they do find it difficult to admit ignorance: but precisely for that reason they miss out on opportunities to learn, and so their expertise is often superficial.
There is a completely different reason why an expert might specifically find change threatening. This is that expert knowledge, practical wisdom, is often largely tacit rather than explicit. It gets embedded in ways of doing things. When the ways of doing things are changed, this knowledge can be irretrievably lost.
(Richard made a point, rather subtly, that the loss that people feel during major transitions in their work is real, being somewhat akin to grief; and that organizations going through transitions would do well to acknowledge this rather than simply wish it away.)
The talk characterized facilitative management as involving a lot of listening and asking of questions (as opposed to simply telling people what to do). This is a topic I would have liked to have seen covered in more detail, since there’s much more to the asking of questions than there might first appear. Consider, for example, the analysis by Steiner Kvale and Svend Brinkman of the questioning technique shown in Hamlet, act III, scene 2:
Hamlet: Do you see yonder cloud that’s almost in shape of a camel?
Polonius: By th’ mass, and ’tis like a camel indeed.
Hamlet: Methinks it is like a weasel.
Polonius: It is back’d like a weasel.
Hamlet: Or like a whale?
Polonius: Very like a whale.
Hamlet: (Aside) They fool me to the top of my bent.
Svale and Brinkman say (InterViews: Learning the Craft of Qualitative Research Interviewing, 2nd ed., p. 162)
At first glance the interview is an example of an unreliable technique—by using three leading questions Hamlet leads Polonius to give three entirely different answers. Thus the interview does not yield any reproducible, reliable knowledge about the shape of the cloud in question.
At second glance, the topic of the interview might change: The figure in question is no longer the cloud, but the personality of Polonius and his trustworthiness. The interview then provide reliable, thrice-checked knowledge about Polonius as an unreliable person—his three different answers are all led by Hamlet’s question.
Of course, not all of us have quite this level of expertise in sussing people out. Normally, understanding people takes time. When you realize how important it is to have time for people, the phrase “cash rich, time poor” can sound like a paraphrase of “cash rich, living dead”.
There was an interesting example given of how a manager at a software company where Richard once worked managed to finesse having time for members of her team. They had a jigsaw puzzle. At the end of every day they would sit down together, and spend some time on it. Having something to gently absorb their attention gave them a way of winding down from whatever stressful project they were on, before they all went home. But it also gave the manager a chance to check up on people, to find out if there was anything she should know.
Richard, a native of Southern California of Maltese descent now living in Austria, also paid tribute to the great British tradition of going to the pub as a means of establishing group cohesion. And, quite properly then, the evening was rounded off by a trip to GE’s local. I did have more to say about this, in connection with remarks about how teams (and companies) get reputations. However, I feel I’ve said quite enough already. Another time, perhaps.
Leave a Reply