Interactive, Push, Pull: Choosing the Right Communication Channel on Purpose
Audit a struggling project's communication and a pattern appears with remarkable consistency: everything is on the wrong channel. Decisions being attempted in email threads eleven replies deep. Critical warnings buried in a wiki nobody was told to read. Status meetings reciting information that should have been a dashboard. PMBOK's classification of communication into interactive, push, and pull sounds almost too simple to be useful, and then you use it as a routing rule and half the noise in a project disappears.
Interactive: expensive, and the only channel that confirms understanding
Interactive communication, meetings, calls, live chat exchanges, is the only mode where you learn in real time whether the other person understood, and where misunderstanding gets corrected in seconds instead of sprints. That property is precious and costly, which is why I ration it, as covered in the meetings post: decisions, disagreements, sensitive messages, and anything where the response changes what happens next.
Working across offices and time zones for years added a sharper rule: interactive hours that overlap two countries' working days are the scarcest resource on the project. Spending that golden window on status recitals, information that could have been pushed, is the most common self-inflicted wound in distributed delivery.
Push: reliable delivery, no proof of comprehension
Push communication sends information to chosen recipients: email, reports, announcements. Its property is delivery without confirmation, people received it, whether they absorbed it is unknown. Push is right for records of decisions, scheduled reports, and anything needing a paper trail. The classic push mistake is escalating stakes without changing channel: burying "the go-live date moved" in paragraph four of a weekly email, then being surprised at the surprise. My rule of thumb: the more a message changes someone's plans, the less it belongs in push alone. Big changes get push for the record plus interactive for the confirmation.
The second push discipline is compression. Nobody rereads a wall; the report that gets absorbed is the one where the three things that matter are the first three lines. Every status artifact I send is built headline-first for exactly the reason progress measurement exists: consumers of project information act on what they notice, not on what was technically sent.
Pull: scales infinitely, guarantees nothing
Pull communication is information made available for self-service: wikis, dashboards, repositories, the tracker itself. It scales to any audience at zero marginal cost, and it guarantees absolutely nothing about who looks. Pull is the right home for reference material, evolving documentation, and live status, the things people need at unpredictable moments. It is the wrong sole home for anything mandatory. "It was on the wiki" is the epitaph of many failed handoffs; pull content that matters needs a push announcement pointing at it, and anything critical needs interactive confirmation on top.
Pull's quiet superpower on my projects is deflection: every question that becomes a dashboard or a runbook page is a question nobody asks a human again. A team drowning in interruptions usually has a pull layer that is missing or untrustworthy, and fixing the layer is cheaper than answering forever.
The routing habit
The practical version of all this is one small habit: before sending anything nontrivial, one deliberate beat, does this need confirmation (interactive), a record (push), or availability (pull), or a combination? Major decisions on my projects deliberately travel all three: decided live, confirmed in writing, archived where future people will look. That is not bureaucracy; it is the same message meeting three different failure modes. Communication planning in the PMBOK sense is just this habit written down per stakeholder: who needs what, how often, on which channel, decided once instead of improvised nightly. The plan takes an hour. The improvisation, I can report from experience, takes the whole project.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.