Jazz, Agility, Innovation

I was intrigued when I heard about Adrian Cho’s book The Jazz Process: Collaboration, Innovation and Agility. Over the years I’ve enjoyed working on development projects with many, many colleagues who’ve astonished me with their musical intelligence and experience — as players of all sorts of music, composers, or simply with extraordinary deep knowledge. Late night talks with friends and fellow developers in the pub, at meet-ups and conferences, makes it clear that this is a widely accepted phenomenon. So when an active jazz musician who’s also a senior development manager at IBM writes a book on the subject, maybe — just maybe — there’ll be some useful insights, particularly about collaboration and innovation in a large organisation.

I really wanted to like the book, but sadly, I was left feeling that this is not the book it could have been. I guess the first clue is in the title: The Jazz Process. Though the subtitle promises “Collaboration, Innovation, and Agility” you can almost see the ‘TM’ following. Of course, Jazz is also the name of the IBM team collaboration platform, which features (to be fair, not as largely as it might, but still too largely for my taste) in the pages of the book.

The Jazz Process, such as it is, is organised around fourteen principles grouped into four themes: Working (”Use Just Enough Rules”, “Employ Top Talent”, “Put the Team First”, “Build Trust and Respect”, “Commit with Passion”), Collaborating (”Listen for Change”,”Lead on Demand”,”Act Transparently”,”Make Contributions Count”), Executing (”Reduce Friction”,”Maintain Momentum”,”Stay Healthy”) and Innovation (”Exchange Ideas”,”Take Measured Risks”). Pretty much all of these fail the Purchase test: if the negation of the principle is clearly nonsense, then they’re not really saying very much. The problem is, once you’ve said (for example) “Build Trust and Respect”, what are you going to do? You clearly wouldn’t want _not_ to do this, you want to avoid screwing up when it comes to trust and respect, but then what? I’m increasingly of the opinion that if you need a book to tell you to Build Trust, then you’re probably not going to be very good at it. What’s more, I’ve seen teams that were overflowing with trust and respect, but which failed completely at developing products (and teams which were riven with tensions but nevertheless achieved great things).

I’m disappointed in the extensive use of sports and military examples. All interesting, but they’ve all been written about before, and they dilute the focus and message of the book. There’s plenty of more compelling literature on high-performance teams and organisations. The “jocks and marines” school of management writing has its own dangers — it’s easy to get consumed by the metaphors of war and competition, to the detriment of sustainablilty.

It’s also dishonest to write about these things, but not to consider the differences between the domains. Musicians and sportsmen, for example, practice individually — in fact most of their life is individual practice. Teamwork is exercised in group practice — training, rehearsals, woodshedding. The moments of inspired ensemble, amazing moments of hair-raising empathy for players and audiences alike, rest on a huge edifice of work away from the performing arena. Product development isn’t like this — it’s not a performance art. Pointing at these moments of high achievement by supremely gifted individuals and saying this is what teamwork is about is all well and inspirational: but any team working at this level of intensity over a period of days, let alone weeks or months, will burn out quickly. There’s a reason that concerts and gigs are the length they are.

It’s also worth remembering that history of music is full of great ensembles which could hardly be called models of collaborative endeavour away from the stage — Joseph Pelrine points out that knife fights in the Ellington orchestra tour bus were common; Charles Mingus’s relationships with his band sometimes descended into physical assault … there are plenty of stories about rock groups self-destructing, of course, and of classical orchestras and ensembles riven with jealousies, emnities and strife.

The training, education and practice of any skill-based craft is a fascinating area of study. Cho has precious little to say on this subject, which is another opportunity lost: jazz is a learnable — and therefore teachable — skill, and the way it is taught, learned, practiced and absorbed would make an intriguing study. Thing is, I think (in this specific case) you’d need to be really interested in jazz, or in learning, to follow that up. Berkun on project management, Weinberg on consulting, both give a much more vivid feeling about what it means to learn and practice these skills in the world of work. And in a field which Cho doesn’t cover, one of the best books I know about this is Atul Gawunde’s “Better”: Gawunde writes with a great deal of self-insight into what it means to train as a surgeon.

The great danger of this sort of book (the same danger as with all those books on military teamwork, for example) is that people will read it and think they have acquired some special insight into what jazz has to teach us about our work: as Ira Gershwin wrote, “It ain’t necessarily so”.

No Comments

Add your own comment...