A Deadline Is a Constraint, Not a Threat | Julien May

Skip to main

A Deadline Is a Constraint, Not a Threat

A deadline appears from somewhere above. The scope is already fixed. The complexity is underestimated. The team is told that it is “empowered”, which somehow means that it is now responsible for making the impossible possible. Quality becomes the thing everyone still talks about, but nobody has time to protect. People start cutting corners, but quietly, because admitting reality has become more expensive than pretending.

This is especially true when the date, scope, quality, and uncertainty are all treated as unchangeable facts. The damage starts when people pretend that a fixed date also means everything else must stay fixed.

That kind of deadline usually reduces quality.

However, I believe there can be another version of a deadline. One that is less about pressure and more about focus. Less about control and more about making decisions. Less about pretending complexity is not there and more about finally giving it an order.

To me, a deadline worth having does not ignore complexity. It gives complexity an order.

When Autonomy Still Gets Stuck

I have seen teams get stuck even when they were genuinely autonomous. Not fake-autonomous in the “you can decide as long as you decide what we already wanted” sense. I mean teams with smart people, good intentions, real ownership, and enough freedom to make decisions.

Autonomy is important, but autonomy does not magically create clarity. A team can be autonomous and still turn in circles. Sometimes because the problem is genuinely hard. Sometimes because the existing system has too many hidden traps. Sometimes because the business goal sounds simple, but the product has years of decisions baked into it. Sometimes because every option has a downside and nobody wants to be the person who chooses the wrong one.

A deadline can become useful exactly in those moments, when autonomy alone is not enough to create sequence.

A stuck team usually does not need someone to take the work away from them. But it also does not need someone standing at a distance saying, “I trust you, just figure it out.” That can sound supportive, but when people are already turning in circles, it often only adds loneliness to the problem. In those moments, doing nothing is not respect for autonomy. It is neglect with better branding.

What often helps is someone stepping into the details with the team. Not to micromanage or dictate the solution, but to understand what the team is worried about, what they have already tried, where they see risk, and where the conversation keeps looping.

That usually takes more than one meeting. If a team has been circling around the same topic for a while, the details often need to be unpacked over several conversations. And sometimes, someone from the outside can help precisely because they do not carry all the same assumptions, frustrations, and history as the team.

Once the details are on the table, they still need to be weighted. Some are essential and dangerous if ignored. Some are annoying but survivable. Some are real, but not first. Worrying about whether a new field might later become configurable can be real architectural thinking. But if the current problem is to support one known rule safely, configurability may not be first.

The point is not to avoid the details. The point is to make the details useful.

This boundary matters. Stepping into the details does not mean deciding how the code should be written. It means understanding the shape of the problem well enough to help the team decide what must come first. The moment leadership uses the details to take control of the solution, a deadline becomes a threat again.

There is a very specific kind of engineering paralysis where everything feels relevant. Every edge case deserves attention. Every future requirement should be considered. Every abstraction could become important. Every shortcut could come back later and punch you in the face. And because all of that is technically true, it becomes very hard to move.

The problem is that “technically true” is not the same as “equally important”.

When everything feels equally important, nothing moves. And when nothing moves for long enough, something else starts to happen. The team loses confidence. Not all at once. Slowly. Quietly. People start to doubt their own judgement. Meetings become heavier. Decisions become harder. Every new option feels like another chance to be wrong.

At that point, the team does not need another abstract discussion about autonomy. It needs a small win. Not a rushed mess that creates more damage than progress. But a coherent change that can be completed, shipped, observed, and learned from.

When Small Is Not the Same as Coherent

In software, things often look small from the outside. A new field. A new status. A new button. A new integration. A small...