Loops Communication Model

No waste of time. No miscommunication

The Tower of Babel by Pieter Bruegel the Elder (1563)

UPDATE: From now on, I would like to call it Loops Communication Model (LCM) as the feedback loop is the basic unit of the whole theory and its core element.

It does not matter how many tools we use. In a professional environment there is always something misunderstood and noises introduced. This comes from contradictory statements and it leads to the denial of agreements.

Lets get our hands dirty. There are many typical failures in working environments. But most of these failures has communication with stakeholders as a seed of the problem.

By following the different communication models, it is pretty simple to see what it means at this level, how it is established and what is required to improve it. But are we adopting any communication model once we start talking? Yes, we do. Instinctively. This is why it is really difficult to achieve a proper level of clean communication in any environment.

The bases of any communication is the use of mutually understood signs and semiotic rules (see Communication). In a professional environment, as a specialized interactional context, the communication between different parts must be defined following the same rules.

This is when the problems start to flourish.

The main modern pillar of progress in product development (e.g.) is transparency. As many times it is mentioned as the bridge between knowing and doing. It sounds good right? Almost perfect to be honest. But transparency is indeed extremely difficult to master.

Let’s take Product Management as an example. The definition of knowing in a product development environment refers directly to the knowledge about our customers (we do have several types of customers). But there is one thing in common in the interaction between Product and Customers. Conceptually, there could be a message and there could be a feedback.

It is crystal clear that unilateral communication does not help to improve any product. Therefore there is the need to create feedback loops where the counterparts react over the given message. Feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause-effect that forms a circuit or loop. Therefore, creating feedback loops is the only way to speed up working processes.

Let’s put this in economic terms: you receive a service, you pay for it. You receive a product, you could give your feedback if you want it to get better. You give your feedback to the service provider and they have the chance to improve their services, bringing you to a better experience. This is a simple transactional model of communication. The basic premise of this model is that individuals are simultaneously engaging with sending and receiving messages.

What if we define structural messages as templates to be sent from sources to receivers? Lets call these templates as contracts between the source and the receiver. Getting back to the service provider: It is easy to define 2 types of contracts between service provider and customer. The service is the first contract. The feedback is the second one. They could have variation but the structure of the contracts is the same.

But, having contracts between the different parts is certainly not enough. There should be a common ubiquitous language to be spoken by the source and understood by the receiver and vice versa.

The concept was already coined on Eric Evans’s “Domain Driven Design” (2003) which consists notably of striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product but in discussions of design as well and all the way into “the products source code itself”.

“(…)the technical vocabulary often tends to “leak” out from reasonable boundaries and take over design conversations to the point where business experts start feeling alienated and disengage from crucial conversations.

Deliberately and explicitly adopting a “ubiquitous language” policy mitigates these difficulties and is therefore a success factor in agile projects.”

But what if we take this concept to a new level?

The Common Language

Every company is divided by departments, divisions, units, etc. Each of these divisions speak an inner fluid language that sometimes is interpreted wrongly and taken from members of another departments, bringing misunderstanding and not desirable outcomes, delays on development or misbehaviors.

All this is consequence of a twisted communication. The first need to solve this issue in any small or big company is to create a common language spoken by everyone. Without a common language, there is no medium of communication and the same mistakes will be repeated. Infinitely.

Most of the failures have a common factor: lack of communication. And many of those communication issues are based on not clear statements, colliding ideas, not enough alignments between counterparts. Not clear records.

That may not sound like much, but records are remembering.

What? Blockchain? Yes, B-L-O-C-K-C-H-A-I-N

As many of you recently were getting into the Blockchain concept, maybe you have been asking yourselves “What is this guy thinking by mentioning Blockchain in this article?”. Well, the Blockchain’s concept uses a terminology (and structure) that is pretty similar to some communication models. Especially the transactional model of communication.

Let’s touch the concept of Blockchain.

“A blockchain can serve as an open, distributed ledger that can record transactions between 2 parties efficiently and in a verifiable and permanent way. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for validating new blocks. Starting with a strong focus on financial applications, blockchain technology is extending to activities including decentralized applications and collaborative organizations that eliminate a middleman.”

Let’s play around with the concepts a little, take the abstract structure behind Blockchain and apply it on the transactional model of communication in order to create a common language to facilitate and simplify the communication between the source and receiver.

As mentioned before, any unit in any company tends to speak an inner language. Meaning, the more units, the more inner languages, thus creating a large amount of interpretations for the same topic. Customers speak a language. Sales speaks a language. And developers and designers speak another kind of languages.

Now, in Blockchain every agreement, every process, every task, every transaction would have a record and signature that could be identified, validated, stored, and shared. And of course, remembered. As mentioned on InVision’s article “The user experience of Blockchain” it could be defined something like this:

• Network participants (Nodes): Different user roles that interact with the blockchain. The Nodes can be different entities.

• Assets: Objects the user interacts with.

• Transaction Flow: Input, logic, and output of a transaction. Similar to a single task-flow analysis performed by a specific user role.

• Network: Set of participants.

• Channel: Sub-networks to allow private interactions between participants.

• Smart contracts: This is the behavior users agree to follow in a blockchain.

Notice that all open Transactions are visible and known by every node of a Network.

Now We Are Talking

By the definition of network participants, assets, transaction flow, network, channel and smart contracts we are defining a solid and transparent transactional communication model, where the source trades with the receiver. It is defined by the transaction flows. The traded objects are the assets. The smart contracts are the rules of the system.

That’s it.

We are establishing a co-regulated, transparent, transactional communication system.

Several smart contracts can be defined between the different units of a company. This might be defined by all stakeholders involved into a network. Once the contracts are defined, the transaction flows are the next. And this is nothing else that the life-cycle of a smart contract. It will close the transaction between source and receiver speeding up the collaboration between nodes and improving the communication process.

So, Blockchain’s abstract model can help to improve the working processes and have an impact on the relational behaviors of any company by creating a common language. What next? Once this is properly implemented, the companies can reach the level of shared knowledge at most levels and between different networks (units). And with shared knowledge comes the development of a collective memory…

Thanks for reading! If you enjoyed this story, please click the 👏 button and share to help others find it! Feel free to leave a comment 💬 below.Have feedback? Let’s be friends on Twitter.