Bridging the gap between design and engineering cultures

A few years ago I conducted a workshop on ethnographic mapping methods with a Pueblo community in the Southwest. While I wasn’t familiar with Pueblo cultures, I had heard they were rigorously private. For example, I was asked not to discuss the specific details of the Pueblo’s history or personal stories—normally a key topic in the workshop.

Despite these precautions, I was surprised when the group seemed unimpressed by the exercises in the workshop. They were often hesitant to participate, especially in the exercises that focused on developing skills for mapping personal stories, historical accounts, and cultural data. I was told, instead, that they were not prepared to talk about these things in the presence of outsiders—meaning myself and some other attendees from a nearby Pueblo. Instead, they asked for handouts.

During the course of the day, I realized that my audience was more prepared for a lecture style than for participatory exercises. They seemed reticent to engage in brainstorming. They just wanted handouts.

The workshop did not go as well as I had hoped. For a long time after the meeting I tried to figure out what they had been looking for from me. If they hadn’t wanted to participate with me, then what had they wanted? Slowly a realization dawned on me, and it had something to do with those handouts.
While there were numerous factors at work—from different learning styles to a deep respect for the role of oration—there was a key point that I had neglected to grasp: what they wanted from me was information—by itself.

I have come to believe the members of the Pueblo were not interested in developing new ideas with me present. Instead, they wanted to bring the information that I presented back into their own group where, through established procedures, they would assess what was valuable to them and what was not.

I’m guessing that respected decision-makers would facilitate this process, using long-standing methods to scrutinize what was useful, then decide on a direction to move in. In their minds, my presence was not valuable to their process, but the information I was delivering might be.

This type of scrutiny of new information may well have enabled Pueblo communities to evolve in a sophisticated manner, maintaining important cultural traditions while modernizing their practices at their own pace to meet their own needs. Keeping a watchful eye over the adoption of new information and methods is a part of their internal process.

The more I work with software engineers, the more I am reminded of the Pueblo workshop experience. Developers, like the members of the Pueblo community, want details. They want information they can take back and talk about on their own. They want the space to decide, based on their own criteria, what is valuable and what is not. They make use of the divide between designers and developers to help maintain their boundaries.

Resistance

Peter Block, in his book Flawless Consulting, calls this strategy resistance, but I think we miss an important insight if we think of this as merely individual resistance. At times, it is resistance to what the designers want. However, in terms of what the developers want, it may be a natural assertion of something akin to cultural unity and autonomy. While Block makes useful suggestions for how to ease the concerns of individual managers or participants, designers may gain greater understanding of the issues involved in collaborations with engineers if they apply some of the concepts of social organizations.

In Getting to Yes: Negotiating Agreement without Giving In, authors Roger Fisher and William Ury are acutely aware of the difficulties of negotiating cultural differences in groups. Fisher and Ury, researchers at the Harvard Negotiation Project, suggest that differences can be overcome, in part, through their recognition. That is, one valuable technique for coming to agreement is to recognize the differences (or positions) among members of a group, but then focus on shared interests. Understanding group and cultural dynamics at work in client organizations can help designers move toward successful collaborations in their projects.

The Power of Handouts

This theory was supported during a recent meeting some fellow designers and I had with a group of software engineers. The meeting was a collaborative session to discuss implementation questions that arose for the development team. For instance, when they were unable to deploy a particular design solution that we suggested due to a technological constraint, we would work together to find a different solution they felt confident they could implement. To explore and discuss these possible work-arounds, the design team sketched new design ideas on the whiteboard.

I learned after the meeting that the engineers were not confident about the whiteboard sketches. Although the ideas from the meeting were clear as we progressed, the sketches did not hold enough information in themselves. Instead, the developers wanted handouts. They wanted documentation they could take back with them, pore over, compare with existing documentation, and annotate.

The power of handouts cannot be overestimated. Handouts and other tools, when written in a language that is clear to developers, provide the time and space necessary for developers to translate designs into system architecture. Likewise, it is important for designers and developers to agree upon the tools that will be shared for describing and discussing design ideas.

Beware, however, that these tools may come with a hidden expectation. In some cases, handouts may only reinforce the cultural divide. If, like the Pueblo community, developers think of handouts as a replacement for collaboration—or learning new ideas together—then the design may be better served by a combination of handouts and a process that helps the developers and designers to build a shared knowledge of the design and its justifications.

The benefit of looking beyond resistance to see a (possible) cultural divide is that it allows us to recognize different groups inside a client organization. For example, resistance itself may be more than just personal expression; it may be an expression of a larger cultural difference that has little to do with foot-dragging and everything to do with managing change in a manner appropriate to that group.

Thinking of companies as clusters of distinct business cultures, with developers making up one of these unique cultures, can provide designers with meaningful insight into effective collaboration with those various internal groups, on their own terms.

References
Block, Peter. 1981. Flawless Consulting: A Guide to Getting Your Expertise Used. Jossey-Bass Pfeiffer, San Francisco.

Fisher, Roger and Ury, William. 1991. Getting to Yes: Negotiating Agreement Without Giving In. Penguin Books, New York.

1 Comment

Rick
Now if only I could remember to live by these rules... expcet for hugging animals and touching screens. Joe can't get mad at me for touching my own computer!

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment