Event-driven communication
How to improve internal communication, based on insights from event-driven architecture
How to improve internal communication, based on insights from event-driven architecture
The problem
Interpersonal communication is a complex skill to master. It is also essential for anyone who works in a team, especially in a product team. Consider a group of four members working on different projects and tasks, needing to be constantly in sync. The challenge becomes even more prominent when communicating with other teams and departments, as often Product Managers do.
How can we improve our communication skills, master this art, and not be overwhelmed by it?
I’d like to suggest an approach inspired by event-driven architecture.
Event-driven architecture
Event-driven architecture in software design encourages decoupling between services by communicating through events. Events represent things that happen (after they happened) and are sent to other services with interest.
This pattern includes three main parts — the message producer, the message consumer, and the router. Below is a demonstration of such architecture.
Let’s demonstrate what the process of paying for an order might look like in a workflow approach versus an event-driven one.
In the workflow approach, we have one main flow that involves multiple services trying to achieve the goal of completing an order. It’s a synchronous flow where a tiny error fails the entire process.
In the event-driven approach, we have several independent flows triggered by events where each contributes to the goal of paying for an order. The main pro is fewer dependencies and the ability to recover from errors.
Insights
When trying to see the characteristics of the event-driven approach in a more abstract way, I find some valuable insights -
Events are objective — an event is something that happened without other parties’ expectations. For example, an event like “Order Created.”
The medium is essential — the one point of failure for such a design is the event router. Besides the fact it needs to work, it also needs to send the events to the correct location, in the proper order, and at the right time.
Minimum dependency — the objectiveness and usage of the suitable medium allows different parts of the system to grow independently with minimum breaking changes.
Let’s see how we can apply these insights to day-to-day communication.
Tips for better communication
Objectiveness
Avoid making assumptions about who is interested in your information and why. For example, let’s consider you’re writing a business case or a requirement document about a particular feature.
One way to go is to pick the people you expect feedback from and engage with them, asking directly for their feedback on their area of expertise on what you’ve built. The second way, the objective way, is to share an event like “PRD ready.” Imagine a message like this one -
“The requirement document on feature X is ready and available for feedback. Any insight, question, or concern is welcome”.
The message receivers, on the other side, are now free to make their decisions about it and whether they want to engage in this communication.
Medium
Your goal and what you want to achieve is the place to start with. Like the router in the event-driven architecture, you need suitable measures so your message will reach the right audience at the right time. Based on that, you should select the proper tool and medium.
Let’s consider a feature release message and three different ways to convey the massage based on the goal -
Recognition — if the goal is to get recognition for the deliverable, a 5-minute slideshow in the monthly company meeting is an excellent medium.
Alignment — if the goal is to align different teams on a new feature and their next task, a one-pager of release notes with action items is a great way to go.
Familiarity — if the goal is to get as many teams as possible familiar with the new feature, a 3-minute video could do the trick.
Start with what you want your consumers to do and your goal, and work your way backward to the best medium.
Dependency
There’s an essential principle in event-driven architecture. Sending a message and forgetting about it won’t work. We want to ensure we get the correct feedback. Here is the flow I would apply to champion dependencies -
Monitor — manage a list of responses you expect, and monitor the answers you get.
Hooks — find the best channels to get inputs back. Just like you’re sending messages, others are doing it too. It could be a Slack channel of releases if you’re waiting for one, subscribing to a Jira ticket that you expect progress on, or just reading emails.
Polling — every once in a while, a week, for example, you cross sections one and two. You find the messages you decided to monitor, cross out those you got hooks for, and you remain with the open ones. Act on those messages and get the feedback you need (like asking a specific team directly for an update).
Summary
Event-driven architecture allowed services to grow independently and scale to new heights. I believe we can learn some great insights and apply them to internal communications, thus helping us reduce overhead and increase efficiency.
The key concepts are keeping communication objective and inclusive, using a suitable medium, and working on getting the feedback needed.