A Shared Procedure for Communication and Engineering
If you work in a tech-related field, perhaps you’ve witnessed the following scenario play out in a meeting:
People talking past one another for several minutes before realizing they’re actually discussing completely different — and sometimes exactly the same things; Words being chosen and promptly discarded, only to be redefined and chosen again; Tempers flaring and subsiding so quickly that there’s no way to know how anyone really feels about the topic; 45 minutes in to the meeting, everyone has forgotten why they’re there in the first place, and jumping out the window is starting to seem like a great idea.
More often than not, conversations like this are a pedantic waste of time. Although they may make for lively meetings, they can also lead to unhealthy tension among team members and stalled productivity. As a pattern, these conversations are completely toxic.
I’ve been observing conversations like the one above for a long time, and I’ve come to understand them as the result of people ‘engineering’ a conversation, rather than using the conversation for problem-solving. It’s easy to see why this happens – engineering is an excellent way to solve problems, as it provides us with a lot of tools for working in a logical, methodical way. Helpfully, these tools make every problem model essentially the same, no matter how complex:
We have some source(a computer, some piece of software, etc.)
We give it some input(the data)
We have a destination(where we expect the data to return)
We run some process on it (what happens to the data between the source and destination)
We evaluate the output(was the output what we expected?)
But engineering procedures alone often aren’t enough to solve problems, particularly when working on a cross-functional team that doesn’t necessarily share the same technical background. To have the best chance of success, we need to supplement our engineering tools with communication tools, too. Luckily, there are communication procedures, like engineering ones, that also break issues down to a standard problem model:
“Who says what, to whom, in what channel, with what effect.”
The Structure and Function of Communication in Society (Laswell, 1948)
With these two problem-models in hand, we can compare them side by side and see that they are essentially the same:
Source == Who
Input == What
Destination == Whom
Process == Channel
Output == Effect
Both models require an analysis of each step in order to reach the desired outcome. If the desired outcome isn’t reached, both models can be reverse-engineered. And practioners of both models generally spend more of their time evaluating and learning from the output of the process rather than the input.
This shared procedure is immensely beneficial for problem-solving across functional groups, because it lets us look at engineering as a communication problem and communication as an engineering problem. Technical team members can apply this when they need to make and communicate engineering decisions that impact a project in big ways. Non-technical team members can apply this procedure to better understand an engineering decision, and how it might affect their work on a project.
For example, one of our engineering teams recently did some work with a largely non-technical client project management team. Initially, both teams appeared to be on the same page about the problem, and what the engineering process and communication channels would be in order to reach a solution. However, as work progressed it became clear that the output of our engineering decisions was not translating to the desired effect for the client team. Applying the shared procedure, we were able to analyze the process and diagnose the problem effectively as a group, and each team was able to learn from the process of the other (and without any pedantic meetings!).
This methodology has also helped me craft a management style that allows me to work flexibly across my organization. With it, I can more effectively communicate operational decisions and their impact on our engineering practice. I’m also better able to understand the constraints and needs of our engineering practice, which is the heart and soul of our business.
Theoretically comparing engineering and communication procedures is still a new, abstract notion in my mind. I hope to better understand the relationship between the two as I practice both sets of skills, and continue applying this methodology to problems and teams at work. In the interim, I welcome any thoughts or resources others might have on the topic.