Switch from push to pull communication

Like any good agile project, the Rangers walk the walk and continuously look for ways to improve our own processes.  In this post, we’ll examine communication, which lies at the heart of any good team. 

Historically, the Rangers have relied on email, which is a form of push communication, and which, as the name implies, means that the sender of a message would need to broadcast that they are looking for a resource, such as more members of their team or letting a group know where something is.  This works in the strictest sense; however, it generates a lot of noise because a lot of people are receiving messages for things that don’t apply to them.  The burden then falls to recipients to sift through all this noise to find the nuggets that do apply to them.  Ultimately, this is burdensome and inefficient.  This diagram illustrates the noise and potential confusion of the many-to-many communication paradigm:


By switching to a pull methodology, in our case, the collaboration tool Slack, many of these challenges can be addressed.  In pull communication, rather than, say, a team looking for new members by broadcasting out an email, people in need of a project would review a central posting of current projects in Slack or a web page with that project’s goals and staffing needs.  Then, the potential member would reach out directly to the team to join.  Only the relevant participants in the communication need to see the messages rather than a number of additional people for whom the messages have no meaning.  Noise goes down.  Efficiency goes up.  People still get what they need, and, in many cases, they will get it faster because they didn’t have to sort through all of that additional noise.  You can see how much more focused the communication is in this diagram:


This approach was not without its challenges, however.  When we first made the switch, one of the biggest changes was to change from using email, an inherently push-oriented mechanism to using the collaboration tool Slack, which is, by default, a pull mechanism… users go to the tool to catch up on communications rather than the messages coming to them.  Some members found the change grating and complained; however, for those people who still prefer the push style, we just had to demonstrate that even in a tool like Slack, you can set an option to receive a push email every time something is posted.  You can set a similar mechanism in Visual Studio Team Services (VSTS), which the Rangers also use heavily.  In this way, we were able to a accommodate both approaches.  It took me a while to get used to the pull model; however, the visual cue by Slack and the "custom" emails triggered by VSTS and Slack have enabled me to focus on what's important.

What do you think of this approach?  Feel free to leave a comment or start a conversation!

Comments (0)

Skip to main content