This is a brief reflection on how we can better represent problems which require decision making from audiences which don’t have the knowledge, understanding or the time to learn about critical technical concepts which make the difference in the business strategy of their company.
I identify myself professionally as an architect and in 2017 this is old fashioned and even controversial. Scan the job search websites advertising hip jobs and you will not come across once against an architect job opening.
I stick however to my “label” for at least two main reasons. First, being an architect represents a way of thinking, acquiring knowledge and solving problems which comes naturally to me. Secondly, architects become all of a sudden required in times of crisis in large organisations when the solving of the problem requires knowledge of vast area of architectural landscape and of several generations of technology. I’ve done this a lot and I find it interesting and rewarding.
However, for most experienced architects I know, the two points above are the pleasant parts of the profession. Seeing the problem is “easy”. Looking for a solution, designing something new is the job. Explaining the problem, the solution, the roadmap for execution and getting decision makers in organisation to pay attention and understand is to me the most difficult part of the job. Over the years I paid attention to various facilitation methods, ways of capturing complex problems in a visual way or even using metaphors. Things are not getting easier though.
Last week a friend sent me a video of a man reading in funny voices a book to baby Margot. “You’ll laugh”, my friend said. I did laugh but what the video reminded me a lot was of myself trying to explain things in the professional environment. (At this point laughing turns into crying.)
“Brown bear brown bear, what do you see
I see a red bird looking at me.
Red bird, red bird, what do you see,
I see a yellow duck looking at me.”
The story is meant to help children associate colours and meaning to objects. As a method though, it is very similar to what I do. I try to represent something which looks like a brown bear, red bird, yellow duck and I try to get the audience to see the brown bear, red bird, yellow duck, etc. See why the bear might kill your organisation or it is scary, critical, strategic,etc. This is not easy though. What looks like a yellow duck to me, looks sometimes like a blue horse to the audience.
Imagine trying to explain what a “container” is, how to select certain APIs or even my favourite topic why the current banking architecture around traditional core banking is a blocker for most digital banking propositions.
After I drew the equivalent of ten brown bear books with various architecture diagrams for banking architecture, I am asking for help and pointers what worked for you out there when you had to explain and represent visually new technology/development paradigms to business strategists. What worked and what didn’t.