I enjoyed that video some time ago, but I really didn't get the takeaway about timelines. Maybe I didn't watch it through.
Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice.
So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible.
Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.
It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.
> Deadlines are about synchronizing different groups
If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role.
Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers.
For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”.
As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving.
Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.
Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice.
So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible.
Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.