Deadlines are good!
"Work expands so as to fill the time available for its completion." – Parkinson’s Law
Yes, it’s a controversial topic, no doubt. Engineers often dislike giving estimates, precisely because of the debates around deadlines. But I encourage you to read this blog with an open mind. And if you strongly disagree, feel free to reach out!
A Story from the Trenches
Our team once embarked on a high-visibility project as a platform team. We drew clear lines between ourselves and the product team, planned the project carefully, and set deadlines based on engineers’ estimates. We factored in story points, QA estimates, and buffers (of course). The timeline? Three months, just for the platform work—without even knowing how long it would take the product team to integrate with us.
Then, everything changed. The CEO called a meeting, asked for an update, and dropped a bombshell:
Cut the deadline in half—release an MVP in 1.5 months, not 3.
Platform engineers need to integrate the product code—even though we had no prior experience with that part of the codebase.
We left the meeting shocked, worried, and, of course, cycling through the classic stages of grief. But after some denial and anger, I called the team to regroup. Here’s what we did:
The Game Plan
We knew 1.5 months wasn’t enough to ship all the features we had envisioned, so we reduced the scope. This exercise involved intense collaboration between Product Managers and Engineers. Together, we focused on what could realistically be completed in the shorter timeline.
Vertical slices, not horizontal layers. Instead of building software in horizontal layers (like backend first, then frontend, then integration), we chose to deliver vertical slices—complete, end-to-end features. This minimized integration time at the end and allowed us to show progress at regular intervals. It also gave QA a chance to build functional tests in parallel with development.
We also planned for regular demos to stakeholders. These were key for keeping everyone in the loop and ensuring that any issues were spotted early. Progress updates every two weeks helped maintain trust, and showing visible advancement helped alleviate the pressure of the reduced timeline.
Key Learnings
Timeline and Scope Are Inextricably Linked. Reducing the timeline without adjusting the scope is a recipe for disaster. Achieving the same scope in less time usually means one of two things: either the original estimate had too much buffer, or the team is being pushed to burnout. Both scenarios reflect poorly on leadership.
Plan for Regular Demos. Demos should be baked into the project plan. Waiting until everything is done to show progress is risky. By the time the project is finished, it could be too late to fix major issues, and you’ve already invested time and money. Regular demos help manage expectations and give stakeholders confidence that the project is on track. Think of them as a “loading status bar” for your project—they show that things are moving, even if slowly.
Work in Vertical Slices. Build features end-to-end so you can demo progress incrementally. Even if some parts are still under construction, show what’s ready. This gives stakeholders visibility and allows them to provide feedback early, while the project is still adaptable.
Testing Should Be Parallel, Not Sequential. QA shouldn’t be an afterthought. Ideally, functional tests should be built as soon as development is complete, allowing for a “crab approach,” where testing follows just behind development. This keeps quality checks continuous, rather than crammed in at the end.
Clarity Drives Speed. When everyone knows their role and the overall project plan is clear, execution speeds up. Momentum builds, and before you know it, deadlines are met. Assigning a dedicated project lead can also help maintain this clarity and pace.
Success Breeds Success—But Beware of Burnout. Once a team experiences success, they’ll want to keep that momentum going. But leaders need to be careful of burnout. A well-functioning team can handle big challenges, but only if they’re paced correctly.
Deadlines: A Double-Edged Sword
Unrealistic Deadlines: Aggressive timelines can lead to cutting corners, burnout, and a final product that’s far from perfect. If the pressure is too high, the cost of errors, rework, and team turnover can outweigh the benefits.
Creativity Under Pressure: Yes, deadlines can stifle creativity. Engineers and designers may opt for the quickest solution, rather than the best one. Deadlines need to be balanced—hard enough to push, but soft enough to allow creativity. Fun fact: many of Leonardo Da Vinci’s works were never completed because he didn’t impose deadlines on himself. A classic case of Parkinson’s Law in action!
Deadline Over Value: Sometimes, the focus shifts from delivering value to just hitting a date. That’s when projects start suffering from the "tick-the-box" mentality, where meeting the deadline becomes more important than solving the actual problem.
Demoralization and Impact on Collaboration: Constant deadline pressure demoralizes teams, leading to burnout and turnover. A demoralized team doesn’t just lose productivity—it also loses its collaborative spirit.
The Takeaway
Deadlines are necessary, but they must be balanced with the realities of scope, risk, and team dynamics. If used thoughtfully, they can sharpen focus and drive success. If imposed recklessly, they can crush creativity and ruin team morale. Use them wisely, and don’t forget that your team’s well-being and the value delivered are as important as the date on the calendar.
