Bob Lambert

The March 2010 issue of The Atlantic features an article called “Management Secrets of the Grateful Dead.” It’s a great read, especially the second half, which tells of the band’s innovations in organization, fan loyalty, and, perhaps counterintuitively, creating value by freely giving away their product. The success of these measures seems self evident: the Dead were “one of the most profitable bands of all time” and almost singlehandedly created an entire product category, jam bands. As a result, the article recounts, the Dead are replacing companies like Southwest Airlines and GE as management training examples of strategic innovators.

As good as it is, to me the article conjured an unlikely vision of the Dead as business men in hippie drag self-consciously making strategy decisions that altered the marketing landscape. I agree that the Dead took the actions cited on purpose, but I believe core product, not marketing strategy, consumed the band’s energies during its formative and peak years.   Could it be that their innovative market strategies grew organically from a quality product, where quality included the entire fan experience?

I hope those teaching Grateful Dead management include this:

• Develop and maintain a strong product
• Risk everything to make the product top quality
• Perfect every detail of the customers’ experience

Develop and maintain a strong product

Given their image, it is easy for non-fans to lose sight of the fact that the Dead were good at what they did.  While one could argue aimlessly about how good they were, they certainly didn’t suffer the unevenness of musicality of some rock ‘n’ roll bands, and they proved it live most days of any given year.  Phil Lesh’s memoir recalls the words of Dizzy Gillespie, passing by an outdoor concert in the late ’60s: “Those cats can swing!”  Lesh himself was a student of jazz and then avant garde composers like Stockhausen before joining the Warlocks, as they were first named.  Mickey Hart was and remains a student of primitive percussion. According to Lesh, Jerry Garcia learned to play the pedal steel guitar in a matter of weeks, quite an accomplishment for an instrument that requires both hands, both feet, and knees to control.

They applied these skills in a joyous, educated, and well-crafted way that reflected musical practice, discipline, and breadth, gluing songs of separate genres together with rocking transitions that frequently dissolved into organic free jams, only to come back together somewhere entirely unexpected.  Even beyond their widely varying originals, their diverse covers were an encyclopedia of mid-twentieth century folk/pop, including Harry Belafonte, Merle Haggard, Buddy Holly, Marty Robbins, and many others.

Risk everything for top quality

Early on the members of the Grateful Dead were steadily less satisfied with the quality of the then-prevailing live sound technology.  Their dissatisfaction peaked in the early seventies, when, according to soundman Dan Healy, they sunk “90 percent of their total earnings” toward building a sound system so that their faithful could “go to the show and hear the heavenly choir, so to speak, through the heavenly sound system.”  Their sacrifice to quality was such that “there were times when we spent the money on speakers and nobody got paychecks, from Jerry on down.”

The dream emerged as the Wall of Sound, a behemoth sound system that “took four semi-trailer trucks and more than 20 crew members to haul and set up.” While the wall of sound itself became too costly to lug around with the fuel crisis of the mid seventies, the Dead retained top notch sound quality after its demise, and its technical innovation remains with us today.  For example, the wall of sound introduced the practice of mic-ing each instrument separately, enabling the sound engineer to deliver a live show with the balance of a recording – standard practice today but revolutionary at the time.

Perfect every detail of the customer’s experience

The Grateful Dead were central to the Haight-Ashbury hippie scene in the sixties, a culture that embraced “Eastern philosophy, championed sexual liberation, promoted the use of psychedelic drugs which they felt expanded one’s consciousness, [and] used alternative arts, street theatre, folk music, and psychedelic rock as a part of their lifestyle and as a way of expressing their feelings.” (here)  Hippie culture came together in “happenings”, free form gatherings “during which music, psychedelic experimentation, a unique sense of personal style and … light shows combined to create a new sense of community”.   The focus of the happening was on the totality of the experience, bringing all elements together to join the participants and spectators (in as much as there was such a distinction) into a single mind.

As freaky as all this sounds, the happening’s focus on the shared gestalt surely fostered the Grateful Dead’s attention to audience experience.  I saw the Dead only once, but it was an outstanding show. Every detail seemed to have been choreographed for the experience of the listener.  The sound was big but not loud and every nuance was clearly audible. Stage and house lighting were perfect. Security was ubiquitous, proactive, and polite.  No detail interfered with band/audience community. Needless to say the Dead rocked the house.

—

Sadly, it couldn’t last forever.  A reviewer of Lesh’s book recounts the decline that started during the late eighties as drug-related health problems, constant touring, the changing nature of their fan base, and the sheer weight of their growing organization bore down on the band. It seems every long, strange, trip has its long strange decline – and perhaps there are management secrets there as well.

Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010

I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink.

Groupthink is a situation where a team’s decision process breaks down and the team reaches decisions that aren’t fully vetted and evaluated.  Both Watergate and the Bay of Pigs fiasco are cited as examples (here).  I’ve seen groupthink operate on IT projects, and to me the agile method’s effectiveness in enabling groups to work together means agile projects are particularly susceptible.

This post reviews groupthink then discusses how the architect on an agile project might help prevent it.

Groupthink

From the Wikipedia article on groupthink, “groupthink is a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas. Individual creativity, uniqueness, and independent thinking are lost in the pursuit of group cohesiveness. During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking…Highly cohesive groups are much more likely to engage in groupthink, because their cohesiveness often correlates with unspoken understanding and the ability to work together with minimal explanations.”

In my experience risk of groupthink can manifest in several ways on IT projects:

• Not Invented Here: Successful teams that work through conflict can settle into a shared culture that resists new ideas from outside the team.
• The Know It All: Less successfully integrated teams can be dominated by a single strong-willed individual, and can habitually avoid conflict by accepting without question the ideas of that one dominant team member.
• The Abilene Paradox: Team members sometimes collectively decide on a course of action that no one on the team likes, when each member actually disagrees with the decision but mistakenly believes that their own preferences are counter to the group’s.

The Agile Architect

According to the Psychologists for Social Responsibility, the standard remedies for groupthink include this: “At least one articulate and knowledgeable member should be given the role of devil’s advocate (to question assumptions and plans)”. Of course the architect is an integral part of the overall project, but the skilled practitioner participates with the Agile team while maintaining separateness in order to remain a source of ideas from outside the team, and therefore provide a counterweight to groupthink by recognizing it and taking measures to prevent it.  Andrew Johnston’s site agilearchitect.org describes some of the ways the architect is in but not totally of the team (here). Among the architect’s responsibilities, he or she:

• Ensures “the delivered system is consistent with the agreed architecture, and will meet the requirements”
• “Is frequently an evangelist for new or different technologies, processes or solutions”
• “Acts as a bridge between developers, managers and other communities, and spends much of his time translating and mediating between them”
• “Recognizes the wide range of stakeholders, and their needs and concerns.”

While core agile team members are immersed in the scope and design that defines the current sprint, the architect retains a larger perspective that encompasses alternative designs, emerging technologies, business fit, stakeholder concerns, and more. The architect is therefore uniquely positioned to recognize groupthink effects on the team’s technical activities. Here are two examples of how that works on agile projects:

• Estimations and retrospectives: Mark Needham, in this post, cites risk of groupthink in agile estimation sessions and retrospectives.  The architect can address both of these risks. In estimation, the architect brings the diverse perspective that Mr. Needham says is important when team members estimate incorrectly due to incorrect team-shared assumptions. In retrospectives, the architect can be the one to increase the “safety” of different perspectives by raising or encouraging others to raise “things that have gone well, not gone well, and things that are confusing”.
• Work product reviews: I’m an advocate of code walkthroughs and design reviews, and making them explicit sprint tasks. The team can set aside an hour or two a week to review one or two representative work products in order to share ideas, ensure quality, and uncover overlooked errors or opportunities. In this forum the architect has the opportunity to reinforce quality work that is aligned with the requriements and architecture, or supportively correct deficiencies.

Of course there are risks:

• The architect shouldn’t be the know it all: In some cases the architect can be the strong-willed individual who stifles creativity and causes the team to avoid conflict.  Strong teamwork and interpersonal skills are core to the agile method, and those who staff the project must include those skills in selection and evaluation of the architect.
• Keep the architect different: If the architect is a core member of the team, he or she can become integrated into the group and therefore part of a groupthink dynamic.  For this reason, I advocate architects being assigned part-time to agile efforts. Otherwise, the architect risks becoming the extra developer, as near term sprint tasks expand to fill the available team bandwidth.  Consider sharing the architect among two or three projects, or assigning him or her responsibility for technical strategy and planning.