New project announcement
I shipped skillcraft.ai - a tool that helps you find the best learning resources tailored to your goals. All you need to do is tell it what you want to learn, and I’ll find the right resources to get you there.
Up to date
Published
4 min read

Trevor I. Lasn

Building tools for developers. Currently building skillcraft.ai and blamesteve.lol

Unrealistic Deadlines In Software Engineering

Unrealistic deadlines are more than just stressful—they set engineers up for failure

When deadlines are too tight, engineers are forced to cut corners. It might mean less time for proper testing, skipping code reviews, or ignoring edge cases. While this might seem fine to non-engineers in the short term, it’s a ticking time bomb. These shortcuts lead to bugs, crashes, and technical debt that has to be cleaned up later.

But here’s the frustrating part: when things break, no one talks about how the deadline was unreasonable. It’s always the engineer’s fault for missing something.

Often, engineers are forced to rush things. Maybe the product manager pushed an aggressive deadline, or leadership wanted a shiny feature in the next release. The problem? Rushed work means higher risk of bugs. But when things break, nobody points at the tight timeline. It’s the engineer who missed something, right?

Who Pays the Price?

When a rushed project goes live and fails, it’s the engineers who are left scrambling to fix it. You’re the one who gets the 3 AM call when the system crashes, even though the unrealistic timeline made failure almost inevitable. Meanwhile, the deadline setters—product managers, executives, whoever—move on to the next big thing.

Cutting corners might get you to the finish line on time, but it often leads to bigger problems down the road. If we don’t start pushing back against these unreasonable expectations, engineers will continue to take the heat for problems that were baked into the timeline from the start.

So, What Can We Do About It?

One of the most effective ways to handle unrealistic deadlines is to set clear expectations from the start. When you’re asked to deliver a feature in an impossible timeline, be upfront about what’s feasible. If you know the feature needs thorough testing, explain the risks of skipping that step.

Practical Tip: When given a deadline, break the project into phases:

  • Phase 1: Minimal viable product (MVP).
  • Phase 2: Testing and validation.
  • Phase 3: Post-launch improvements.

If the deadline is tight, push for at least delivering the MVP first and make it clear what the trade-offs will be (e.g., reduced scope, possible bugs).

Example Conversation:

“We can hit the deadline, but we’ll have to scale back on testing. There’s a risk we’ll miss edge cases, and this could result in bugs down the line. If you want more thorough testing, we’ll need an extra week.”

This shows you’re being realistic, not just resistant, and makes the risks clear upfront.

Push Back When Necessary

It can be tough to push back against deadlines, but sometimes it’s necessary. If you feel like a timeline is putting the project at risk, speak up. As engineers, we’re responsible for delivering quality, not just hitting dates.

If a product manager demands a feature that you know is going to break under a tight deadline, have a constructive conversation. Use data from past projects to show what happens when deadlines are rushed—bug reports, downtime, or increased post-launch maintenance.

“Last time we rushed the XYZ feature, we had a 30% increase in post-launch bug reports. This could hurt user experience and take up more time later. I’d recommend we spend more time testing up front.”

One reason deadlines get pushed aggressively is that leadership often doesn’t see the risks of cutting corners. They see the launch date, but not the hours of bug fixing that follow a rushed release. It’s up to us to make those risks visible.

If you’re forced into a tight deadline, document your concerns. This isn’t about pointing fingers later—it’s about making sure there’s a record of the risks you highlighted. If things go wrong, you can point to the documentation and say, “We knew this could happen, and here’s why.”


Found this article helpful? You might enjoy my free newsletter. I share dev tips and insights to help you grow your coding skills and advance your tech career.


Check out these related articles that might be useful for you. They cover similar topics and provide additional insights.

Reflections
5 min read

A Company Is Not a Family. It's a Sports Team

'We're not just a company, we're a family!' It's a nice sentiment, sure. But it's also a load of crap.

Oct 5, 2024
Read article
Reflections
4 min read

Write Documentation Like a Journalist

Create comprehensive, engaging documentation by adopting journalistic techniques for research and storytelling

Sep 26, 2024
Read article
Reflections
5 min read

Advice to New Engineering Managers

Tips for being an effective engineering leader and how to avoid common pitfalls

Feb 15, 2025
Read article
Reflections
7 min read

The Real Cost of Meetings: What FAANG Companies Do Differently

Discover how FAANG companies like Amazon, Google, and Netflix reduce the hidden costs of meetings by embracing written communication and minimizing unnecessary gatherings.

Sep 17, 2024
Read article
Reflections
4 min read

A Great Product Doesn't Need Marketing

Great products speak for themselves, without the need for massive marketing campaigns

Sep 18, 2024
Read article
Reflections
4 min read

High Performing Engineer Teams = motivation + enthusiasm + autonomy

Create the conditions where engineers want to excel and they'll surpass your expectations

Mar 7, 2025
Read article
Reflections
3 min read

The 5:1 Rule: Effective Performance Reviews For High-Performing Teams

Research reveals the ideal ratio of positive to negative feedback within high performing teams

Mar 20, 2025
Read article
Reflections
8 min read

What Makes a Great Engineering Manager?

People don't quit jobs, they quit bad managers. Here's what great engineering leadership actually looks like

Dec 8, 2024
Read article
Reflections
5 min read

Company Culture Happens Outside Management

Why real company culture grows from the ground up, not top down.

Sep 14, 2024
Read article

This article was originally published on https://www.trevorlasn.com/blog/unrealistic-deadlines-in-software-engineering. It was written by a human and polished using grammar tools for clarity.