Push vs. Pull Management

Over the last decade or so I encounter quite a few managers, while each of them was unique in its own way, I roughly found that I can divide them into two main groups according to their strategy.

Pull Managers

On one hand there were managers who were very into what went on always walking around asking question showing interest in everything going on and putting their nose into all places including those it didn’t belong in.

Push managers

in the other group there were those who considered themselves the focal point of their team, they usually got their info by using all kinds of report, they did attend meeting when needed, and naturally they did talk to their team, but most of the time they were minding their own business using their own room to manage the work. and popping from time to time to ask something/direct the work.

While I do have my own preference on how I would like to see managers behave. I do think that you can be successful using either way. I do however feel that there are contexts in which “Pull managers” have a higher chances to succeed.

Pull vs. Push Systems

No I’m not going the Kanban road. I do want to talk about systems design.

question: if you have a system in which a single component needs to keep track of the overall system state how would you design it?

Will you have the various parts of the system “send” their events to this main component (Push) ? or would you have that main component pull the needed information whenever he needs it?

like always the correct answer is: it depends. If you have a very high rate of changes in your system (lets say thousands of events per second) or/and you have a relatively small number of parts. you would most likely prefer a pull mechanism. if however you have a relatively small rate of change or/and a large number of parts you would probably prefer a push mechanism.

Now lets take it into management. I’m used to work in an agile environment. in such an environment that amount of data which is gathered on a daily basis is large. the entire process is created in order to handle changes. and if you do it right most likely there will be a lot of change. and in such an environment if you want to succeed I believe that going the pull way will server you better as a manager.

Trying to sit in your office and expecting the information to come to you will means that you most likely will:

1. annoy your team – demanding them to bring the information to you whether on a daily basis or via and electronic management tool.


2. Miss a lot of the info – since an agile process will focus on verbal communication, there’s a lot going on which is not captured in any written way

Trust me if your managing an agile team you will need to do the Gemba each day

Posted in: Agile Management,Agile Values