Most of the communication occurring among members of a project team is aimed, or should be aimed, at making decisions and enforcing them. Managing a project through its entire lifecycle involves a bewildering number of critical decisions of all sorts, distributed along many dimensions: vision and strategy, technology choices, architecture and detail-level design, requirements from customers, derived from competitive analysis, constraints such as cost, timeline, and so on.

A lot of these decisions, provided that the project’s execution is to be successful, must be made in a tightly interwoven fashion: there are, for instance, complex implications between the availability of a given technology in the market at a given time, the level of expertise in the team for this technology, and the overall strategy and direction adopted by a software or hardware product. And these decisions should be based on the confrontation of as much relevant facts and cross-fact connections as available with the analytical ability of the team as a whole.

How, then, do the communication systems we use affect our ability to reach the right decisions, enforce them, revisit them? More precisely, how do they assist us in gathering, organizing, linking and analyzing the facts, the knowledge so essential to our decisions and ultimately our success? Just as critically, given the scarcity of solid knowledge during the early phases of a project, how do they help in iterating through the on-going process of integrating new facts, additional knowledge in order to confirm or refine those decisions?

Indeed, communication systems and their associated semantics, far from being neutral, transparent bearers of the information they convey, have a major impact on the structure of the exchanges taking place among the parties involved. Therefore, they affect the process of elaborating knowledge, and ultimately the richness, accuracy, and relevance of the facts we gather, categorize, and derive our decisions from.

Consequently, deconstructing team communication patterns is essential in understanding how structured knowledge is elaborated, and used to reach decisions. Such communication patterns are also important in understanding how such knowledge and decisions are then described and shared within and outside the team, as well as kept track of and evolved over the course of the project’s lifecycle.

Given its ubiquity in software development teams, let’s start by looking at the way email, as a communication medium, shapes the decision making and tracking process.

Email-based exchanges, that are message-oriented, carry “differential” semantics: like all conversational systems, they involve the exchange of messages among the parties involved that do not typically contain the entire knowledge shared among those parties. Instead, these entities communicating are responsible both for maintaining the mental image of the knowledge they are sharing, and for amending it continuously as they process the implications on this knowledge of the messages exchanged, containing only additions and changes proposed by one entity to the others.

The activity of constructing and maintaining the mental image of the shared knowledge is work-intensive. Worse, it is a risky task, in that the knowledge elaborated is not really shared directly, but instead maintained in mental images that are actually private to each party.

Therefore, I describe email as a non-cumulative knowledge building system. Not because each message that is exchanged only carries additions or changes to be made to that shared or pseudo-shared mental image, but because the work of processing the meaning of newly received messages is ultimately done by their human recipients.

How does the non-cumulative nature of a system impact the ability of the team to build knowledge?

A non-cumulative medium has many drawbacks, not the least of which is being prone to uncontrolled divergence between the private images of the shared set of facts and cross-fact connections held by the parties involved. Of course, the more parties are involved, the greater the risk of catastrophic divergence.

And the only way such divergences actually get noticed and possibly corrected in such a system is when one of the parties sends a message describing their contributions or additions to the shared knowledge and these additions suddenly fail to fit into the mental representation of the knowledge held by the receiving parties.

The sudden inconsistency prompts for clarifications, retransmissions, and not uncommonly, the rewinding of most of the conversation up to the point where all parties feel, again, confident enough that their private images are describing the same knowledge that they decide proceed forward again.

Such a phenomenon, obviously also found in verbal conversations, is the source of major inefficiencies in the communication, and it stems from the lack of a knowledge base that’s actually shared, and that all communicating parties are observing simultaneously as they evolve it.

Of course, cumulative systems, by contrast, rely on the existence and building of shared knowledge in the system itself, not in the minds of its users. Examples of cumulative systems are databases, shared file systems.

But what’s missing from a database of shared file system is the ability to exchange contributions and observations about the facts being shared, and thus augment, modify, refine the knowledge set of the group, within the boundaries of the system itself. Hence the appearance of out-of-band communications, typically taking the form of email exchanges, where additional knowledge is therefore appearing, outside of the shared system, at least until someone decides to feed their private cumulative image of the exchange back into the shared system. Quite a daunting effort!

The underlying challenge, thus, becomes: how can we integrate a cumulative shared system with a non-cumulative messaging system to support the on-going elaboration and refinement of structured knowledge, in a continuous, inline fashion, from a unified interface avoiding disruptions and rifts in the communication semantics?