Keep it visible, smartass

"Can't you add it later?"

Imagine that there's a discussion between two architects and a sponsor regarding technical debt that enormously slows down the delivery of new features.

The team is already behind the schedule, everyone is getting nervous, including management, as dates and potential benefits were communicated through PowerPoint presentation months ago.

Architects have an idea to gradually migrate two architectural elements into modern .NET, but most importantly to re-establish internal boundaries in each of them.

Re-align application architecture.

In their evaluation, this will enable faster incrementing of features across the entire system.

Two architects were left in the virtual meeting room, discussing how hard it is for other people to understand typical problems of a technologists.

"Aren't you interested in the code?"

The same organization, but different discussion - this time three developers collaborate on how to deliver a functionality, given the current structure of the module they both work on.

The change itself isn't a big one, but it requires touching many submodules, each having a different responsibility.

Also, one of them is a newcomer, not knowing the system.

They continued the discussion for next hour, in which David, the Developer asked many more questions, trying to wrap his head around the codebase.

Because all is about the code, right?

"It will take time to put everything in text!"

Yet again the same company but different people setup - a product owner and two software engineers discussing potential new feature.

Product owner speaks about his requirements and customer needs.

Software engineers try to ask clarifying questions and explore potential invisible problems.

They didn't note anything down.

When the next meeting happened, no one really remembered, nor understood, what they had agreed on.

The great confusion appeared as Peter, the Product Owner changed the words he used for concepts related to this feature.

It took time to restore understanding.

Understanding?

"People struggle communicating with each other, what's a big deal?" - one might easily ask.

Turns out that software development is a social activity - as Kent Beck taught us with his wise words.

Social activity meaning a lot of communication, ideas transferring and building shared understanding.

Building trust and relationships because without them, collaboration and effective problem-solving become challenging.

Or even impossible.

What do those two tales have in common?

I hope you read the title, dear Reader, because they both strive to communicate missing something vastly relevant - visual communication.

How often did you participate in a meeting and no one was sharing anything?

Just a bunch of pixel avatars (because everyone is too shy to turn on their cameras) talking to each other, making bold statements and pretending to be very smart in another person's eyes.

UFC-like match between egos, trying to play the dominance game, not asking "What do you mean by that?" so that they keep perpetuating the illusion that everyone is on the same page.

And then, customers suffer, as they didn't get what they truly needed.

Recipients and consumers fail to get value delivered, because of poor, internal communication.

Things get delayed as someone "just misunderstood the intentions".

Misunderstood... Or maybe they were communicated poorly?

"Communication always fails, except by accident"

I've heard this phrase from Woody Zuill, which turned out to be one of Wiio's laws.

It brings harsh reality of being a human - we are inherently prone to miscommunication.

Recipient of the message may interpret it differently than intended.

The message itself might be convoluted enough to make it difficult to decode (which is a nice metaphor itself - like trying to read a book in a foreign language without a dictionary).

Interlocutors exchanging varying models of the reality, different perspectives, which easily lead to assumption-based communication.

When we converse with others, we not only publish and receive information, but also implicitly exchange mental models (models of thinking and processing information), which might be one big and invisible obstacle in communication.

Architects thinking in bigger pictures, developers thinking in details (btw. nice stereotype, isn't it dear Reader?).

Sponsors thinking in money and market shares.

And so on.

How on earth those roles can effectively collaborate?

Even though language is hugely important in our lives, it is inherently limited and prone to misinterpretation.

Language means words, and when we "peek inside a box", of "a word", by checking one of many definitions:

We quickly might realize that words are sounds which have finite energy associated with them, which means that energy can quickly dissipate.

When spoken, words are impermanent, they are invisible and volatile.

Sounds translated to symbols, and their meaning can vary depending on the context and the interpreting party.

Or misinterpreting, if you wish, dear Reader.

Keep it visible, smartass

Let's get back to the definition we conjured a while ago, but now focusing on another part of it:

Just by making things visible, we can reduce the chances of miscommunication and ensure that everyone is on the same page.

Representing impermanent sound as a symbol is the way to go to fight against assumptions, lack of clarity and misinterpretation.

Paraphrasing Alberto Brandolini's words: "don't talk about invisible things" (I believe he was the author of those words).

"Woah, thank you captain obvious" - someone can say in their head.

It might sound trivial, but it's a crucial point.

Because it's obvious, it's easily overlooked.

Especially when it is not trained enough.

And yes, this is a skill.

It needs to be practiced consciously when we are collaborating with others.

And no, one does not need to be an architect to draw things on the board or be a scrum master to note things down.

One needs to be a human being.

The quality of visuals - well, that's a different story.

What does "X" mean?

Let's say you are discussing integration between two services and there's a strange wording that is even difficult to pronounce.

It is not the first time you chat about it but somehow no diagram is readily available.

One could say - a perfect setup, free from sources of confusion.

There might be an implicit assumption that there will be no assumptions, because the topic is pretty well-known.

Write down this word.

Draw two boxes and a line.

Assign meaning to each by writing it down.

Will it make the conversation longer?

Well, maybe the first time.

"Head is the worst place to keep problems and ideas", as my friend Przemek Wolnik taught me once.

Make things visible, explicit and represented.

Whenever a new concept arises in verbal conversation, put it into a visual form.

We often struggle if we can't mention things by their name, as naming is framing.

It is actually useful and crucial process so that we can exchange information (and mental models) and collaborate.

Going back to integration between two services - imagine what happens if parties discussing the problem have never experienced this topic before.

They don't have the shared context or mental models to understand each other fully.

And someone frames the meeting by saying "we only have 30 minutes".

"We need to be efficient" - one might say aloud.

Everything will be successful, right dear Reader?

Miscommunication visualized

As Dijkstra said:

Drawing, writing - not in the secrecy - but in the public space, while chatting with others, is not to prove how smart one is.

It is to reveal the assumptions, gaps, and misunderstandings that might otherwise remain hidden.

We could use wise words from Dijkstra and create something similar but for visual collaboration:

Of course, the trust and positive intentions are preliminary condition to move forward.

Whenever a conversation starts and no one shares anything in a couple of minutes - grab a screen or walk to a whiteboard and start sketching whatever you hear.

Yes, there is a high chance it will be a complete failure.

This time.

But do you, dear Reader, know what the FAIL acronym means?

It's good to be wrong for a short period of time.

It's not that good to be wrong for a loooooooong period of time.

Better to FAIL fast, gather feedback and reconfigure (avoiding being (fr)Agile).

Ability to say "I don't know" separates mature beings from the rest.

And yes, it might mean all will need to slow down, at least while starting.

But this is "production capabilities" investment.

Putting effort into advancing people's capabilities in understanding a problem/a solution/a design/a whatever so that value production will come with less effort later.

It is a bet made for the future that there will be decreased rework, reducing waste.

Building shared understanding, considering that people are capable of following, is a key for software development.

Getting back to the drawing board - the next iteration might be more precise to what the mental models of the interlocutors are.

After couple of minutes there will be a shared platform for exchanging thoughts.

Even though people might internally think and talk to themselves that "it's a complete waste", they will suddenly start referring to the drawing or the text.

They will point at it and say "in this thing called X, I think...".

A small, invisible win, which happened because of keeping things visual and not talking about invisible things.

From assumption-based to visual-based communication

Visuals do not need to be advanced, perfect or detailed.

At least not when starting the session.

I really like, after hearing invisible words from my interlocutor, to say: "let me rephrase it using my words to see if I understood you correctly".

I try to keep core concepts (here: words, terms), but use my own sentences, to ensure mutual understanding.

Instead of rephrasing, one could easily say: "let me draw what you just said to see if I follow your thinking correctly".

Putting some boxes, lines and words in visual form creates a platform on which we can exchange mental models, information and doubts.

Suddenly, everyone can point with a finger, ask for clarification and contribute to the shared understanding.

Of course, there are various methods for collaborative modeling: Event Storming, Event Modeling, Domain Storytelling and more.

But the most important thing is to... do it.

Tiny steps, tiny wins.

For sure it will be great to organize a fully fledged session in which people can interact and collaborate, but starting small and iterating is key.

We are typically "two boxes and an arrow" away from changing the habits of our organization or our team.

No more meetings with invisible content - open excalidraw and start sketching.

Invite others.

If they feel insecure, be their guide - let them explain their thinking and you put it down.

Next time, dear Reader, when you collaborate with someone and nothing is visible, draw or write things down and say:

Magic happens when ideas and problems become visible.