Business Communication

The influence of business communication structures on software.

It is rare to see business and technology align to reach a fullness of competitive advantage. If you look carefully at the most successful companies, they are such because of the ability of major stakeholders to communicate laterally, and as a result, the strong human and team partnerships that are formed because a vision is understood and shared. This is not because only one or a few business leaders communicate well. It’s because most involved have formed open and clear communication channels that consistently and constantly harmonize with making vision reality.

Note that lateral communication is key. It means that executives share the responsibility of delivery because they are not talking down to the other people involved. They see themselves as part of the team, which means they see others as part of their team. In the modern era where software is continually eating more and more of the world, old hierarchies of communication cannot last.

Typical business communication structure
Typical business communication structure that results in poor software systems design.

One person understood this well in 1967, and shared his understanding with the world. This person is Melvin (Mel) Conway. He observed that organizations design systems that mirror their own communication structure. This observation has become known as Conway’s Law.

Note that Conway’s Law is not limited to software systems and is equally applicable to any kind of system. Even the operations of a business is a kind of system, from hierarchies to function or dysfunction, because results will occur from the way communication happens. If people see themselves as lesser and driven by command and control, fear and guilt, and the like, the business system itself as a result of that communication structure will dysfunction in exactly those ways. If the business decreases or eliminates hierarchy and literally sees and acknowledges the value of everyone as a team member, the business system itself will thrive, because it will function in exactly those ways.

Lateral Business Communication Diagram
Business communication structure that gives software teams the best chance to succeed.

The same goes for smaller teams that are formed to produce software that makes the business system better than it would be without it. A greater extent of better is only realized as communication drives toward deeper knowledge and continuously examines every conceivable possibility for improvement. This requires respect on all sides, which includes those who are not technology practitioners and those who are. They must respect each other and communicate in a way that engenders the example set by the business leaders. In fact, everyone should be a business leader.

Deep communication, critical thinking, and cooperation are indispensable to achieve disruptive, transformational, software systems. Thinking with a goal toward constant learning is key. What are we doing? Why are we doing it? We must think: informedly; clearly; critically; broadly; deeply; thoroughly. What are the business goals and strategies? What are the service-level requirements? All of these can be achieved without threat to anyone, because they are sought after respectfully. The goal is to learn and learn quickly, which leads to transformational breakthroughs.

We need change in how business stakeholders and software developers interact to achieve better business outcomes with software. This only happens with learning, where increasingly greater degrees of better are realized as our team communication drives toward deeper knowledge and continuously examines every conceivable possibility for improvement.

Simplicity and Domain-Driven Design Friendliness

Opening the best communication structures is why the XOOM platform emphasizes simplicity and friendliness in using the Domain-Oriented Microservices Architecture (DOMA) and Domain-Driven Design (DDD) software development approaches. Our platform toolset provides support for both strategic and tactical design and architecture used to build high-performance, Reactive microservices and well-modularized monoliths.

More to explore

Reactive DDD: Modeling Uncertainty

Domain-Driven Design supports reactive architecture and programming. Still, reactive introduces uncertainty. Back in 2003, the way that Domain-Driven Design was used and

Scroll to Top