Communication

Communication in a project is the deliberate part of getting a message across: what you say, how you deliver it, and through which channel. All three are choices, and the same content can build a team or damage it depending on how they are made.

1. Constructive or destructive is a choice

Constructive communication builds morale, teamwork and relationships; destructive communication produces conflict, resentment and resistance [1]. The content is often identical — only the delivery changed. Two things separate them. Approach is choosing the when and the where, and it is the first thing dropped in a busy week. Building bridges is naming the behaviour rather than the person, and finding the common ground that the disagreement sits on.

For example, “your migration broke production” said in front of nine people at standup, and the same fact raised ten minutes later with the two people who can fix it, carry identical information and produce opposite weeks. Decide where and when before a hard conversation; that is half the decision already made.

2. Listening is a technique, not an attitude

Listening fails in predictable ways, and none of them is a lack of goodwill. It fails when you listen only for facts and miss the concern underneath them; when you compose your reply while the other person is still talking; when you finish their sentences. Thought runs far faster than speech, and the gap fills with your own argument unless you give it something to do.

Giving it something to do is the technique. Paraphrasing is the one move that shows: say back, in your own words, what you think was said, and let the other person correct it. Around that, circulate meeting notes and invite corrections, ask questions that are not challenges, and signal that you are still there — nods, eye contact, and on a call, the camera. Ask, look, listen, and then answer. Paraphrasing is the one technique a room notices, because it is the only one that produces evidence you were listening.

3. Meeting intent decides onsite or remote

The old question was how far apart people sit. The current one is which meetings need a room. In a study of 27 interviews across all 15 agile teams at one Ericsson site, the intent of the meeting decided the useful mode: retrospectives, sprint and user-story planning and technical discussions benefited from being onsite, while large information-sharing meetings worked well — sometimes better — remotely [2]. The same study warns against filling the office days with meetings, because back-to-back sessions destroy the informal conversation that was the reason to come in.

Distance itself matters less than it appears to. Across a review of 255 studies, perceived distance predicted collaboration where spatio-temporal distance did not [3]: without casual encounters, teams substitute assumptions about each other’s effort for observation of it, and those assumptions skew negative.

A model in the conversation is not a neutral pipe either. Collective attention drifts toward whatever an AI participant has just named, even though most participants deny it is part of the team at all — influence without membership, which no media-richness account of a channel predicts [4].

How solid is this?

  • The constructive/destructive contrast is practitioner advice. Arredondo [1] draws it from consulting experience; no effect size attaches to it, and the claim that delivery alone flips the outcome is still to be verified.
  • The listening material is teaching craft, not a research finding. It descends from the small-group communication literature — Harris and Sherblom’s Small Group and Team Communication — and the effect of an active-listening technique on software teams remains to be measured. Use it as a practice to try, not as a demonstrated result.
  • The hybrid-meeting finding is contested, not settled. Christensen and colleagues studied one company at one Finnish site, exploratory and explicitly not causal, and their retrospectives result contradicts prior work that found retrospectives held online for inclusion.
  • The virtual-teams review is narrative, not systematic: no quality appraisal, no effect sizes, and it draws on studies that predate 2019, and so predate mass remote work.
  • The AI result is small and not about software. Undergraduate laboratory teams on a puzzle task; in one condition the “AI” was pre-recorded audio; the flagship effect is roughly one extra word per twenty-word utterance, and the authors state it establishes no base rate for real settings.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [5] on software project management.

References

  1. L. Arredondo,
    Communicating Effectively. McGraw-Hill, 2000.
  2. E. L. Christensen, M. Paasivaara, and I. Salman,
    “Hybrid Work in Agile Software Development: Recurring Meetings,” in 2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE), 2025, pp. 120–130. doi: 10.1109/CHASE66643.2025.00023.
  3. S. Morrison-Smith and J. Ruiz,
    “Challenges and barriers in virtual teams: a literature review,” SN Applied Sciences, vol. 2, no. 6, p. 1096, 2020, doi: 10.1007/s42452-020-2801-5.
  4. C. Riedl, S. Savage, and J. Zvelebilova,
    “Cognitive Spillover in Human-AI Teams.” 2024.
  5. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.