Setting deadlines in software engineering is like scheduling creativity. It doesn’t really work, and pretending it does might end up costing you more than you realize — because deadlines don’t tend to produce quality software.
It can be tempting to treat software development like manufacturing: as if there’s a predictable, linear process from idea to shipped feature. But you likely know as well as I do that this approach can not only fail to deliver faster, but can actively make things worse.
The trust erosion, the rushed work, the technical debt that compounds over months ... and for what? A date on a calendar that was never based on reality in the first place.
At Swarmia, we’ve built a culture that mostly rejects deadlines, because of a practical recognition of how software development actually works — and how to get the best results from engineering teams.
When we set deadlines in software engineering, we’re often misunderstanding the nature of the work.
Writing code is the design part of the process, not the manufacturing part. As Titus Winters from Adobe put it in a recent conversation about software delivery phases, the creative human work part can’t be scheduled like components in a factory process.
Again, the process isn’t linear. You need feedback, you’ll try things that don’t work, and you’ll discover constraints you didn’t know existed.
As an experienced engineer, I can tell you “that should take about a week,” but I can’t say “that will take exactly 42 hours.” Nor should I need to.
I learned this the hard way. My first “real” job was at a newspaper on the night news desk. We had three deadlines every night — real deadlines, where if we missed them, the paper wouldn’t make it onto trucks in time for morning delivery. Those deadlines were motivating and clarifying. They created a common enemy that united the late-night team in purpose.
But newspaper production is manufacturing. Software engineering is not.
The parts of software development that actually are like manufacturing — deployment pipelines, build processes, testing suites — those are exactly the parts we should be automating. It’s exactly why CI/CD exists.
So if and when you find yourself setting deadlines for these repeatable processes, that’s a signal to invest in automation, not project management.
Yes, some deadlines are real. When we have contractual obligations, those dates matter. Sometimes a critical customer needs a feature by their renewal date. Maybe you work in an agency model where contracts are defined by deliverables at deadlines.
But notice what these have in common? They’re externally imposed by actual events or requirements, not artificially created for “motivation” or “speed”.
And even then, meeting these deadlines is a business decision. It’s perfectly fine to communicate that something will be done “in H2″ rather than committing to a specific date. We accept that risk as a business, rather than pushing it down to engineering teams.
Here’s what I’ve observed over decades of working with and without deadlines:
All of these outcomes can lead to teams realizing over time that the deadline is meaningless — often the actual launch or integration or whatever Very Important Thing happens weeks later anyway, or sometimes it never does.
Then, people learn that these made-up deadlines don’t actually matter, and they either stop meeting them or meet them with sub-par quality work. The deadline goes from being a “common enemy” to background chatter that gets ignored.
When that arbitrary deadline passes and the feature isn’t ready (because of course it isn’t — the date was fiction from the start), here’s what happens:
And all of this damage to your culture, your codebase, your team dynamics — again, for what? To maintain the fiction that software development is predictable?
The origin of deadlines in knowledge work is capitalistic mistrust of workers.
It’s a management technique based on the assumption that you can’t trust people to work without external pressure. When you set artificial deadlines, you’re essentially saying to your team: “I don’t trust you to make good decisions about how to spend your time.”
And wouldn’t you know it: when you treat people like they need to be managed with arbitrary deadlines, they start behaving like people who need to be managed with arbitrary deadlines. They optimize for meeting the date, not for building the right thing. And they make short-term decisions because that’s what the system rewards.
In knowledge work, something has to give. Either it’s the deadline, or the scope.
If you absolutely must have a deadline, then scope must be flexible. It’s a mathematical necessity.
As you build, you discover new information that should change what you’re building. Locking both the timeline and the deliverable eliminates the ability to incorporate this learning.
When we rigidly adhere to an initial scope defined before any code was written, we’re essentially saying “we don’t want to learn anything new during development.” But that’s the exact opposite of what should happen. We should be learning and adapting as we go.
Learning through the course of the work will — and absolutely should — change the ultimate deliverable. The optimal solution often emerges when teams have the flexibility to incorporate new insights along the way.
If your organization insists on maintaining both fixed deadlines and fixed scope, what you’re really doing is setting up your for one or more risks:
What this means in practice is that with a deadline, you prioritize ruthlessly, focusing on delivering the highest-value items first. This way, if and when you reach the deadline, you’ve delivered the most important functionality — even if it’s not everything originally envisioned.
Now, I know what you’re thinking: “But work expands to fill available time!” And yes, Parkinson’s Law is real. Without deadlines, some work will take longer than it needs to. But it’s still better than the alternative of rushed, untested code that breaks in production. And it turns out there are better ways to create urgency than arbitrary dates.
At Swarmia, we’ve found several alternatives that work better than deadlines:
Saying “let’s spend no more than a week investigating this” is very different from “this must be done by Friday.” The first acknowledges uncertainty, and the second pretends it doesn’t exist.
These approaches work because they’re honest about uncertainty while still creating accountability.
When teams understand the business need, they can make good decisions about prioritization. You can’t make good decisions about how to spend your time without understanding what the business and customers need.
We sound like a broken record here, but: monitor your cycle times and ship continuously.
When things are flowing smoothly, the pressure for deadlines often disappears.
This isn’t theoretical for us — our teams maintain healthy cycle time without arbitrary deadlines by focusing on continuous flow, keeping work-in-progress low, and maintaining crucial slack time.
Which, of course, allows us to deliver value to customers quickly, with better quality work and happier engineers.
This requires trusting your teams and building healthy relationships between engineering and product management.
The truth is, in a deadline-free world, you need different motivators. It could be cultural, where you’re rewarded for doing the right work at the right time. It could be incentive-based with bonuses. Or it could be intrinsic, where feeling connected to customers and understanding their needs is the reward.
There will be rare times when people need to flex for the business — like working a weekend when something critical breaks. But that should be extremely rare, not an expectation of 80-hour weeks. And it should be recognized as the exception it is, not normalized into “just how we work here.”
Simply announcing “we don’t do deadlines anymore” is just about as effective as announcing “we don’t do bugs anymore.”
The absence of deadlines creates a vacuum, and if you don’t fill that vacuum with something meaningful, you’ll either end up with chaos or (more likely) deadlines will creep back in under different names.
So with that in mind, there are a few things that you’ll need to constantly work on to get people working on the right things, within a reasonable time frame:
Deadlines are a tool for transactional relationships and manufacturing processes. Software development is neither.
At Swarmia, we’ve found that trusting our teams, setting clear goals, and maintaining strong connections to business outcomes creates better software, faster, than artificial deadlines ever could — by replacing the stick of deadlines with the carrot of meaningful work and shared success.
Next time someone insists on a deadline, ask them: “What are you really trying to achieve?” If it’s predictability, show them your cycle time metrics. If it’s urgency, show them your continuous delivery process. If it’s coordination with other teams, offer a better way.
If it’s “motivation” for its own sake, what you really need is trust, clarity, and better communication — not a date on a calendar.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
