Software developers talk about “pushing” and “pulling” information. Let’s define this.
Let’s say, you’re building a software system that has to integrate with another system. For any two systems, these are general principles that always apply. So, I’m writing an email reader for my phone, and it needs to integrate with Gmail to get my email. Or let’s say I’m writing a stock market analysis data program that needs to get information about stock prices from a stock trading platform. There are endless reasons why two systems would need to talk to each other, and they always do.
There are two generalized ways they can interact. One way is that the system you’re building can send a message to the other system requesting some information, which is then sent to you. You “pull” the information from it.
Or, the other system can send information to your system automatically and regularly. Maybe you have an email address that receives emails, or maybe there’s an API that every 30 seconds pings the other systems. There are endless ways to do it. But under this model, the second system “pushes” information to the first system.
Each way has its advantages and disadvantages. Here’s a modern example, all these app notifications I get on my phone, every time someone posts a slack message. Those are “pushing” me information, notifications “push” information. I didn’t want it. But all the time it just gives me information. But when I open my email program to read my email or I open Slack to read Slack, I’m pulling information, I get it when I want it, on my timeline.
With that as background, my advice today is to always push information to your clients. As the corollary to that, if your client is asking you for too much information (that is, he’s pulling information from you), then you’re doing something wrong.
Let me explain.
From the client’s eyes, he just wants to know what’s happening. If he needs to ask and ask for this report or this update, that’s another source of frustration. He’s pulling information from you constantly which to him, feels like he’s pulling teeth. This isn’t fun for anyone, other than masochistic dentists.
On the other hand, when you pro-actively give updates and share information, it makes working with each other a pleasure and removes a major source of frustration.
Let’s make this point clear by comparing two hypothetical chefs. Both make food equally as delicious, so their respective quality isn’t a question at all.
With chef 1, you have to constantly pull information from her. You ask her, “are you going to come tomorrow? Your schedule is to come once per 4 days and tomorrow is the fourth day” to which she responds “Yes, sure.” You ask her, “what are you planning to make for dinner tomorrow?” and she says, “Chicken with mole sauce.” You tell her, “I like my food not too spicy, so can you limit the spices?” and she says, “of course!” The food is delicious.
Now, compare that to chef 2, who pushes information and questions to you. She sends you a message saying, “Hey, since tomorrow is the fourth day since the last time, I came over to cook, I want to confirm that I’m coming over tomorrow at 4pm.” Then she sends you another message a few hours later saying, “For tomorrow’s dinner, I’m planning on making Chicken Mole. I think you’ll love it” and you respond, “sounds great.” She then writes back, “it will be moderately spicy, is that a problem?” to which you respond, “let’s make the moderate just very moderate” to which she responds with an emoji. The food is equally as delicious as the first chef.
Even if the food is just as great for both, the experience of working with the second is 11x the experience of working with the first. And it’s the second chef that gets recommended to all your friends, not the first.
Remember, however, that pushing too much information can easily become a burden and overwhelm your boss or client. It could make it impossible to separate the important from the unimportant plus turn into a too-big time commitment to read all your stuff. My preferred solution is three-fold: first, to get a sense of their preference, often just asking them directly. Secondly, to apply some of my other suggestions from these chapters, like to frame all questions with a default action-item so that questions don’t become a burden (because if they don’t read it or don’t respond, you’re giving the default action yourself and still pushing it ahead.) And third, I push information constantly in channels that I predefine to them to be less important for them to watch closely (such as Slack) and any issues that are more important I clearly flag by tagging them or using language in the email subject line to make the importance clear. But without these three strategies, pushing information can easily turn into a burden, so you need to always be sensitive to that balance.
