When I graduated High School I wanted to be an interpreter. And while I didn’t end up working for the UN, I think in my current role, the art of interpretation is immensely important!

One of the things I’ve learned over the years is that even when we’re all speaking the same language, we’re often not speaking the same language.

Especially when it comes to gathering requirements for a new solution or tool or process. Often, what the end user needs & what we hear are often on completely different planes of existence.

And as Architect/Consultant/Admin/Business Analyst it is our job to try to draw out the consistencies & translate so we are on the same playing field. To poke holes in the requirements, not in an attempt to pop them, but in an attempt to get them down to their most basic.

When a user says ‘automatically’ you can’t always assume this means an automation is required. It could be that they have no concept of what automation can mean in a tool they don’t know. They are using a term to describe that it needs to be easy, user friendly. Not because they need an automation. (We all know what making assumptions does…)

It’s on US to poke at things. To unravel the language barriers & understand the REAL requirements. Sometimes if you step back from the words themselves and put yourself in their shoes, the words sound different. Say ‘show me’ a lot – let them demonstrate how it is now, what they ‘don’t’ want it to do. Peel back the layers.

Learn to be a great interpreter.