brainsnorkel.com

Robert Cialdini’s Inside Influence web site recently ran an article about a social psychological “chameleon effect.” This effect is demonstrated in a study that compares waiters’ tips when they repeat their customers’ order back to them with tips for waiters who simply say something positive after taking an order. In a Dutch study reported by Nature, waiters doubled their average tip by echoing customer orders.

I thought about how this applies to systems engineering. How do stakeholders feel about having their words translated into forms such as use cases, and requirements documents which are intended to be close to, but not quite, stakeholder language. Should stakeholders only be communicated with in their own language? Can they be?

In software and systems engineering much is made of using formal and unambiguous representations like UML with formal structures like use cases. Use cases, user stories and flows are all methods of bridging technical requirements and user needs.

I think it’s well understood that using the language of your audience and targeting their needs as exactly as you can is a golden rule of communication. The golden rule assumes you have the luxury of having an audience uniform enough to address as a bloc is rare in many disciplines and systems engineering is no exception. In my career it has been unusual to find a stakeholder who feels comfortable reviewing use cases.

Taking stakeholder requirements, and communicating it back to them in their own language and without translation sounds like an excellent method of clearing up requirements misunderstandings. It helps in scope and feature negotiations if your customer is predisposed to like you. However, clearing up stakeholder needs is only one step in developing a product.

Stakeholders ultimately need to trust or verify that the product meets their specifications. To do this, they need to be able to relate the acceptance criteria to their original needs or specifications.

Is mimicry useful to help the stakeholder trust that an implementation is a correctly functioning expression of their needs? This is where an ability to read, understand and verify use cases, blank verse requirements and test cases, is a valuable, and rare, skill for stakeholders.

In general, I have found that stakeholders without these skills or the energy to acquire them will either rely on the currency of trust developed in the communication of needs, or they become unsatisfied and frustrated with the developed product.

Does the rest of the Nature article have any other hints for keeping stakeholders happy?

But this is just one of a battery of ploys that waiting staff can use to increase customers’ generosity. Other studies have shown that smiling, greeting and touching the customer, and crouching down beside them while taking orders also lead to bigger tips.

So if I’m working on your project, you’ll find me repeating things you say. I’ll smile at you. I’ll impersonate, greet, crouch beside, and touch you, but I might never show you my use cases.