Image

Software mirrors organizational values, or: an error message annoyed me enough to blog about it.

I just had a moment where several points I’ve been making to colleagues about organizational culture, the myth of software’s neutrality, and poor user experience choices came together in one package. It was the intersection of Conway’s Law, cultural anthropology and user experience design.  Unfortunately, the outcome was… not great.

On my current project, I’m responsible for approving the deployments to the Dev environment.  My project is using Microsoft Team Foundation Server (TFS) for build and release management.  After I approve a deployment, the system provides a response as to the success or failure of the deployment.

For successful deployments, I see this:

Succeeded

Pretty straightforward, right? I can see the request I’d made to the system succeeded, and some metadata about the deployment.

However, when the deployment fails, I see this response:

REJECTED

Uh, what?  Shouldn’t that say “FAILED” instead of “REJECTED?”

This is a perfect example about how the values of an organization slide into the software it produces. From my long experience working with Microsoft products, I know errors are assumed by default to be caused by the user behaving incorrectly with the software, rather than the software failing to meet the expectations of the user.

My expectation is not to have a system “REJECT” my request when it couldn’t successfully complete the requested action, but instead report its own failure.  But Microsoft believes as an organization that users are more likely to misuse their products than their products fail users.  As a result of this attitude, developers frame the status messaging as an assessment of the user’s ability to do things “correctly” rather than the software’s ability to respond as expected to a user request.

There’s been plenty of trench warfare in the UX community about whether systems should apologize for errors, so I won’t rehash that here.  I fall squarely in the camp of being delighted by systems that own their errors, rather than blame me for them.  I was immediately irked at TFS’s rude insistence on leveling its judgement of my deployment request. I’m usually neutral to mildly amused at apologetic messages from the various applications I use that clearly center a user (Chrome and Discord come to mind).

Next time you’re designing or building error handling routines, consider whether your system is both failing its user AND being rude about it.

Argument Culture Kills Creativity

I have a saying: “You can’t innovate in a dangerous environment.”  People need to feel secure in themselves and their situation to be creative, share their ideas, and take risks. If the culture where we work is adversarial, where jockeying for position and playing it safe are de rigeur, we can’t afford to make anything but the safest bets.

Kate Heddleston’s excellent article on Arguments Cultures and Unregulated Aggression describes in detail how the combative practice of argument-as-problem-solving-tool manifests in the tech industry.

We in the tech industry like to tell ourselves we’re making decisions based on facts, logic, and superior reasoning. We also like to tell ourselves that the people and ideas that rise to the top are the ones with the most merit.  Both of these conceits are false.  Humans as a species are pretty terrible at making decisions based on facts.  We respond and act more often from out emotions than our intellect.  Just like the most effective method of influencing is appealing to our emotions, decisions are driven from emotion and bias more often than logic.

Argument as a decision-making tool lacks a core component: ethics.  Rhetoric and debate have ethical ground rules in place for ensuring parties are arguing in good faith. To argue with a bad actor — as is most often the case in a technology solution argument — is a waste of time, intended to exhaust an opponent, not to root out any weakness in the ideas being discussed.  There’s now tech companies advocating for “no discussion” problem-solving, because they view discussion of any kind as a waste of time.

The waste isn’t in discussion, it’s in bad faith arguments.  If we approach every instance of idea sharing as a battle, soon no one wants to share anything at all. There’s no room for creativity when there’s always someone fighting for dominance, or to “win” a conflict.  Having a more humane approach to sharing ideas fosters a creative atmosphere where everyone can bring all their ideas to the table without judgement.

Successful design firms like IDEO embrace the creative with space and culture choices that help foster a safe environment for their teams to bring their most imaginative selves to their work. Especially when brainstorming, when you want to expand on ideas, not eliminate them, there’s no room for combative attitudes or bad faith arguments.  When we feel safe and confident, we can be creative and expand our ideas.  Arguments can wait… or maybe never happen at all.

The Conduit Metaphor of Communication

I find myself telling and retelling this story about the Conduit Metaphor by way of explaining that how we talk about communication is important to understanding where breakdowns in communication can occur in Standard American English speakers.

Michael J. Reddy described in 1979 the Conduit Metaphor used by Standard American English (SAE) speakers. This demonstrates how we think about communication.

Continue reading