This article seems based on the flimsiest logic, or on experience in extremely dysfunctional organizations.

> When teams miss a deadline, it’s too late to take any productive actions.

> Think about the actions you can take once your team misses a deadline:

> 1. Set a new deadline
> 2. Fire someone
> 3. Cut scope

Obviously, if you only discover that you missed the deadline on the day it passes, you can't do anything productive about it. But no one (competent) works like that: you adjust your work and your scope based on the deadline for the entire duration of the project. Starting from basic design ("we need to ship this feature in 2 weeks" will lead to a different design than "we need to ship this feature in 3 months") to design/scope adjustments ("we've been working for one week and we can see this is not going to finish in one more week, do you want us to adjust the scope/design, or is it preferable to push the date further out?").

I suspect a root cause of this problem is the following idea, from the "Queueing disciplines section":

> We can model every software development process as a queueing system. In such a system, tasks come in on one end, and software comes out on the other.

This is a fundamental misunderstanding of how software development works, at least for the vast majority of cases. Tasks are not an input of the software development process, feature requests are. Tasks are an intermediate output - you have to put in work to refine vague feature requests into concrete tasks. The same feature request can be translated into many different tasks, depending on various factors (competition, expected timeline, team experience, external dependencies etc.).

For a concrete example, say the team is working on building an alternative to Wireshark (a packet capture and analysis tool). A PM may ask the team to add support for QUIC to the product. In the ideal case, the tool would be able to understand every kind of QUIC packet, partially recognize some of the more common malformed packets, support decryption of the contents via one or more popular key logging formats etc. But, depending on product architecture, this may take half a year to fully implement.

If the PM desires some minimal support for QUIC in, say, 2 months (perhaps to coincide with some fiscal quarter), then they need to work with the team today to find a meaningful subset of features that can be implemented and delivered in ~2 months. Of course, during those two months, the team may discover that they are working faster or slower than anticipated, and may need to adjust the scope even more. Even so, the deadline may still be missed of course (say, one of the lead developers falls ill two weeks before the deadline, or a fundamental misunderstanding of the protocol that was causing sporadic bugs is understood only 1 week before).

However, if the PM only added a "support QUIC" "task" to the team's queue, with high priority, the team will almost certainly have nothing even close to releasable 2 months after the request was added, even if they are working at the exact same pace - since they focused on a more advanced version of the feature. Even if they are internally working in a way where they avoid having non-releasable features for such a long time, they are very likely to have prioritized other aspects of the feature than what the PM needed, and have only finished and polished those by the (unknown to them) 2 month "deadline".