Kailash Awati and Paul Culmsee

Our book is about why best practices don’t work and what can be done about it. Best practices fail because organisational problems are complex or wicked. The plethora of tools, systems and best practices that are generally used to tackle organisational problems rarely help because they emphasise solutions rather than analysis. Consequently, those who apply these methods often end up solving the wrong problem. A major reason for this is that organisational problems are wicked, and wicked problems are inherently hard to pin down, let alone solve. 

We’ve studied the work of many academics who have recognised and written about this. The problem is that these works challenge many widely accepted views, patterns and practices of various managerial disciplines. As a result these ideas have been rejected, ignored or considered outright heretical, and thus languish (largely unread) in journals. 

We love heretical ideas – particularly when they support conclusions we have reached through our professional experiences. However we like readability even more – interesting ideas are no good if they can only be understood by PhDs. We believe such insights are best conveyed over a social lubricant like beer or a coffee, and so have written this book in an accessible, relaxed and conversational manner.

The first part of the book elaborates on our claim that the lack of shared understanding is the root cause of many organisational dysfunctions. We do so using examples drawn from personal experience, supported by existing research in a range of management disciplines including cognitive science, project management, psychology and evolutionary science. We also draw inspiration from real and fictional luminaries  such as Russell Ackoff  and Willy Wonka.
In the second part of the book we describe a range of problem structuring methods, collaborative tools and technologies  that can help organisations get to a true understanding of a problem before attempting to solve it (…and no, the tools are not just blogs and wikis). Best of all, the tools we discuss are easy to learn; they do not require us to speak a new tongue, sing a new tune or dance a new dance. Whilst most professionals are well versed with conventional management tools, the ones we discuss are yet to gain traction in business environments. We provide a comprehensive introduction to these tools via several non-trivial case studies.

Visualising problems is one of the areas we discuss in our book exclusively for readers of EndUserSharePoint.com. 

How to become the alpha programmer

The story we’re about to relate is from a time when Paul was working for an IT company with a large team of programmers. To set the context for those who aren’t familiar with the inner workings of an IT department, we’ll first spend some time presenting a potted sociology of programmers.

Like any primate, computer programmers often spend their time in large social groups or, as we like to call them, ‘development packs’. These groups are strictly trait based, meaning that they are usually tied to a particular technology.  Programmers from a pack rarely migrate outside of their home range.  Packs usually avoid each other, and are generally aggressive towards broader IT disciplines such as Business Analysts, System Administrators and project managers. Consequently, social interactions between members of different troops are fairly uncommon.

Like all primate groups, development packs have a strict hierarchy. The group is led by an alpha programmer who achieves his status by displaying real – or quite often, imagined – programming prowess. This may sound a bit cynical, but it’s largely true: alpha programmers often get to where they are by bluffing, and calling the bluffs of other members of the development pack. There are showdowns when an individual in the alpha position is challenged, and this happens often, because programmers tend to overrate their abilities and hold strong opinions, much like humans in most walks of life.  Consequently, alphas may have to “fight” individuals in their group several times in order to hang on to their positions.

Junior programmers have to go through the process of ‘developer adolescence/puberty’. If these juniors see something wrong and dare to say anything about it, they risk being “shot down” by the alpha senior. This happens regardless of whether the junior is right or wrong: the norms of the social hierarchy require that alphas assert themselves so as to maintain their top dog status. As time goes on, the ‘developer adolescent’ becomes an adult, and in the process learns that proving alpha status in the development pack is achieved by trampling on others’ opinions and abilities; the way to the top is paved with deflated programmer egos, so to speak. Achieving alpha status means that one has “arrived.” Among other things, alpha programmers’ opinions and ideas are rarely questioned. They get their way the most of the time.

When an alpha is challenged, the forum is almost always email, with the rest of the pack being cc’d on the battle. Paul was witness to such a challenge when he was working in a group in which a newly hired senior programmer (who had reached adulthood from a different development pack) questioned the implementation approach of the current alpha programmer. The incumbent alpha had written a detailed technical specification outlining his preferred solution and why it was the right thing to do. Paul questioned the approach because he saw that it would have a negative impact on the area that he (Paul) was responsible for. However, try as he did, Paul could not get the alpha programmer to see the point. There were two reasons for this. Firstly, the argument was conducted via email –  Paul opted to counter the alpha’s wordy email with more email prose. As anyone who has attempted to argue via email will know from experience – countering prose with more prose. rarely works. Secondly, since Paul was not a programmer, and was an outsider as far as the development pack was concerned, trying to go up against the alpha was futile. Paul’s saviour was the alpha challenger, who was able to usurp the incumbent with an email that contained no text whatsoever – just the following two images.

         

The point made here is so obvious that it needs no elaboration.  There was no reply from the incumbent alpha; he slunk off to the back of the pack, his status forever relegated to that of a junior pack member. Needless to say, his solution went the way he did.

Why the manual sucks (and people never read them)

Most people dislike writing reports or essays.  Firstly, the amount of effort it would take say, to codify a deep, hour-long conversation between two people into a written form would take substantially longer than the conversation itself. Secondly, it is much harder to explain complex ideas in prose than it is to do in a face-to-face conversation. In the latter, one has the advantage of being able to see the other person’s reaction, and adjust the explanation to match their understanding. 

Yet most of us have been saddled with the riveting task of writing business documents such as project proposals, business cases, technology evaluations, functional specifications and so on.  The typical organisation, generates and prints reams of these documents daily, so there’s no escape for the average corporate minion. 

Typically business documents are aimed at conveying positions or ideas to a specific audience. For example, a business case might detail the rationale behind (and hence the justification for) a project to executive management. The hardest part of composing these is the flow: how ideas are introduced, explained and transitioned one after the other. The organisation of a document has to be carefully thought through because of the difficulty in conveying complex, interconnected ideas in writing.

That’s not all, there is a deeper problem:  prose makes it hard to systematically evaluate ideas because the relationships between those ideas are not immediately evident. Given that we all have differing world views, readers then have to decode the relationships and connections between ideas. In writing this book, Paul and Kailash have often read the same paper and come away with differing interpretations of the ideas discussed.

This is one reason why IKEA’s manuals contain no prose at all (actually it is the reason).  The power of images in conveying ideas cannot be overstated. After all, it took only two cleverly juxtaposed images to vanquish a certain alpha programmer.

From Walnuts to Mice and Men

Edward C. Tolman was one of those professors who liked to put hungry rats in a maze to observe how they learned to find food hidden in it. After performing a series of experiments, Tolman argued that over time, rats built “cognitive maps” which provided them a mental representation of the maze.  These maps enabled them to navigate the maze and find the food faster.

Similarly, while a person may not be able to remember what happened on a night of alcoholic overindulgence, he may yet have managed to find his way back home even though he may not be able to explain how he did so. Like the rat that has leaned where the food is, the fact that someone completely plastered can still wake up in their own bed is suggests that we all possess cognitive maps of concepts and relationships that we have learnt and experienced.

Our grey matter seems to have many of these cognitive maps laid down and refined over time. They enable us to see and interpret a given situation in different ways, depending on context, need and even mood. Sometimes we experience one of those serendipitous moments where we can suddenly ‘see’ information in a different light or make a connection between our cognitive maps that we previously not aware of.

It isn’t a stretch to say that many great discoveries arose from   well posed, incisive questions which enabled people to change their frame of reference and experience an “aha” moment. The power that a well framed question has to enable us to “see” something in a completely different light cannot be underestimated. Clearly, asking the right question can lead to insight and breakthrough. But we have other ways that we can also improve our cognitive maps as well.

If we accept that cognitive maps are internal, mental maps of concepts and relationships (or, more picturesquely, “signposts for thought”) then it isn’t a stretch to say that external representations of concepts and their relationships to each other can also augment our ability to the processes of thinking and learning. In simple terms: visual representations (i.e. pictures!) can help guide our thinking.

However vanquishing alpha programmers and putting together cheap furniture is one thing; solving issues such as climate change or peak oil is quite another.  Problems in the latter category are wicked – i.e. they are so complex and intractable, that there is no agreement as to what the problem is, let alone its solution. If wicked problems were solvable simply by displaying questions and rationale in the form of clever cartoons or a pictures, then surely, we would have solved them by now. As it stands many of us can’t even put together an Ikea bookshelf without swearing at the manual.

One of the themes we examine in our book is how pictures, symbols and text are used to convey meaning for complex problems. We delve into the key elements for really effective communication of complex ideas, and discuss why well-designed visual representations can help in tackling some of the most complex problems organisations face.

Please see the following links to learn more about Beyond Best Practices:

http://www.cleverworkarounds.com/2010/06/07/why-ive-been-quiet/
http://eight2late.wordpress.com/2010/06/07/beyond-best-practices-a-paper-review-and-the-genesis-of-a-collaboration/

Guest Author: Kailash Awati

Kailash Awati is a lapsed physicist who currently works as a project and development team manager at a pharmaceutical multinational in Australia. He blogs at Eight to Late where he writes about projects, organisations and the people who make them.

Author: Paul Culmsee
www.sevensigma.com.au