 If there is one habit that software organisations cling to longer than any other, it is starting work to feel in control. As if making the decision gives people some sort of satisfaction or power. Roadmaps get refined, plans get approved, quarters get kicked off. Then work starts because it’s “time” and not because the system is ready. Just… because we have it on the list. Tell me your organisation is not at least a little bit like this?
Pull signals are the antidote to that habit. And they are very uncomfortable for most organisations that have become used to equating motion with progress. Why most organisations still push (even if they say they don’t) Many teams claim to be running a “pull-based” system, but if you examine what they actually do, you discover a different story. What you very often see is that work starts when one of these is true:
None of these are pull signals. Work is pushed into the system based on time, authority, or anxiety. And often you find that WIP limits do exist on their board, but they are routinely overridden “just this once”. And then, over time, the system stops signalling anything meaningful, and WIP limits become decorative. Here’s a simple way to tell: If starting work does not require an explicit signal from the system, you do not have pull. What represents a Pull signal Just to make it clear. When a person decides or tells the team to start something, this isn’t a pull signal. A pull signal can only come from the system itself. It is a system condition that the team has agreed to implement and when that condition flags up, it says: “We now have capacity to finish something new.” Most teams implement a very simple pull signal - when WIP drops below its limit. But this isn’t the only pull signal you can implement. There are variety of signals that more mature systems might choose to implement. These include:
Why starting work is the most dangerous decision you make From the perspective of flow finishing work reduces risk and starting work increases it. This may sound simplistic but consider what are the consequences every time you start something new
And yet, starting work is often treated as a win - at least we’ve started it! Well implemented pull signals force organisations to consider the true cost of starting. It’s just a matter of paying attention to the signals. Visible pull signals make trade-offs explicit Which is probably the main reason they are being avoided. Push systems are attractive because they avoid hard choices. When everything is “important”, it’s easy to accept that everything starts. The trade-offs are deferred to later, when urgency and politics take over. It’s a vicious cycle that many organisations never find a way out of. When you use a real pull system then this logic is completely inverted. When the system tells you there is “no capacity” then leaders are forced to answer important questions “Which work finishes first?” “Which work waits?”, “What gets dropped?”, etc. Of course, these are uncomfortable conversations so it’s easier if we avoid them. Using pull signals properly ensures we can’t do the avoiding part. Teams can’t enforce pull on their own It’s all good to talk about implementing a pull system from the bottom up, but without leaders’ support it won’t be an effective pull system. Expecting teams to “just pull better” is not a realistic strategy because teams rarely control things like demand, priority changes, expedited work, cross team dependencies or organisation urgency. When your leadership continues to introduce new work or expedite items regardless of system state, then your pull system collapses. In order to have an effective pull system leadership must respect the pull signals. This brings us to a very important point. One that brings together all previous posts in this series. And that is because pull signals depend on all of the below:
Without these, pull signals are either ignored or overridden. With them, the system starts to regulate itself. A proper Pull system requires patience When organisations transitioning from push to actual pull they often experience an uncomfortable initial phase. Suddenly managers see fewer things get started and queues become visible. Then delays that were always there become more obvious and overall progress seems slower. It’s easy to see how leadership may see this as things getting worse. But this is not a failure. It is the mostly the same system but now it has gained the ability to tell you how overloaded it already is. A Push system hides these signals by spreading risk and delays thinly across many items. Pull concentrates attention where it matters and thus changes where leadership needs to focus. In a traditional push organisations it is common for leaders to spends their time chasing status, expediting work, resolving dependencies or conflicts and explaining missed commitments. While in pull systems, their attention shifts to removing blockers, managing WIP, improving flow and making earlier trade-offs. This leads to less drama and more focus on flow. The problem with Expedites You may think that expedited items are proper pull because the organisation needs them. That’s not true for all the reasons explained earlier. Expedited items are exceptions. They can happen since every organisation sometimes has expedited work. But you need to treat such work as rare and an exception. Make sure the impact to other work and the cost are obvious. If you treat expedited work as normal very soon everything becomes expedited, but in reality nothing really is. Pull systems can tolerate exceptions but you can’t hide the impact. Acting on system signals is a leadership responsibility We have reached the hardest part of pull-based systems. If system signals are ignored outside of the remit of the team the pull system will not function. Leaders must be willing to act or wait when system says so. This will absolutely feel like loss of control which is what makes it really hard. But when done right, it changes control from instinct to evidence. Pull signals don’t remove the need for leadership judgement. They inform it with data. Pull signals the end of these series and the beginning of real flow The pull signals element of the Kanban system are at the end of this series to underpin their importance. There cannot be faked or bolted on. They can’t be enforced with process alone. Pull signals require all of the below:
When all of this is true Kanban metrics become very powerful. They are no longer reports but signals the organisation actually listens to. Reach that point and flow is not just an aspiration but a property of the system. And that’s when delivery leadership finally becomes calm, boring, and effective. Sounds good, doesn’t it? Links to all articles in the series here |
Welcome to my blog!About the authorPlamen is an experienced Software Delivery consultant helping organisations around the world identify their path to success and follow it. 
Archives
April 2026
Categories
All
|
RSS Feed
