Hello, fellows, and welcome to today's podcast.
I want to delve into a topic crucial for anyone involved in development, whether on a team or within an entire organization: the relentless loop of deadlines. Deadlines are often seen as a tool to drive productivity, providing that external push to get things done. However, this constant rush can develop into a habit that, while initially practical, eventually creates a cycle of stress and stifles innovation.
Throughout my career, I have observed how teams thrive when given the autonomy to innovate and take ownership of their work rather than being confined by rigid deadlines.
When prioritizing continuous improvement and frequent feedback over chasing deadlines, we reduce stress and foster a culture of responsibility and creativity. This approach bridges the gap between development and business, creating a cohesive, effective, and motivated team.
But we need to be on time!!!
Being on time and deadlines are two different pairs of shoes. Deadline is a practice and often an organizational habit. Being on time is a responsibility, something we commit to.
Every time we invested time and thought into the process, we came out with something more valuable.
Every time we solely focused on deadlines, we took the shortest route to get stuff done; often, we took shortcuts when the timeframe was too narrow. Which resulted in adverse long-term effects on NFRs.
How do we balance deadlines and innovation?
We cannot just switch to something different when we have developed a deadline habit as a team, organization, or company.
In fellowships and mentoring, this is often the main topic. A person or a team understands that a switch is necessary, but the way to change the bad habits is hard.
It is too late; engineers realize that the quality of the code base is below the defined quality or recognize that they are constantly rushing from one deadline to the other.
More problems occur over time because this practice doesn’t provide time to get things into shape.
Engineers take short-cuts:
Avoiding Tests
Skipping refactoring
Avoid improvements
Ignoring technical debt.
Management became used to defining timeframes based on estimations, based on half-baked requirements, and shallow context. It’s then up to the engineers to find ways to mitigate this tension.
What really worries me is when engineers defend deadlines.
I don’t really know what I should think at that moment. It’s often based on a thought like
“We were successful once when we set ourselves a deadline. We keep on doing that.”
“If a company perpetuates the narrative that 'the business needs it, or else it's over,”
– it's a sign that you've been misled. Such an organization isn't open to change. It operates in a way that remains detached from engineering, making it easier for them to justify their decisions without emotional investment. If this is the case, consider leaving the company.
Unfortunately, that ignores the harmful long-term effects on our qualities and working culture.
Responsibility and Ownership are the first victims of this practice. Why should a person take ownership of something that is:
Time budgeted.
Fixed in scope.
Fixed in execution.
Already pre-defined in the requirements.
It’s just something an engineering team will work down to make it happen to a specific date: the deadline.
The results of this lack of ownership will be:
No care for tests
No care for quality
No care for feedback.
No care for improvement.
No care for resilience & maintainability
Simply put, no one cares at some point; people slowly burn out, and you won’t see something until it’s too late: Quit quitting.
The solution is simple yet hard to understand.
We need to trust that software engineers, who get paid well, can take responsibility and ownership while keeping timelines in mind.
By its nature, development describes an iterative, exploratory process, not a timeframe. Developers can handle that well, but you need to let them.
Rephrase deadlines to timelines or milestones. Communicate why getting a specific set of features is essential until X.
But don’t use this as a deadline to squeeze more development performance out of the people. Instead of narrowing down timeframes and making deadlines harder to meet, provide more leeway to keep qualities and let improvements happen.
You will see a constant, positive process, which will still work in months to come. You will have a good chance to prevent a legacy state, a problem nearly every company I know personally has.
Start to trust your developers, rethink your expectations, and understand software and product development as an exploratory process. Include everyone and remove the huge gap between engineering and business.
Key takeaways
Deadlines often create a cycle of stress and limit innovation.
Deadlines should be used sparingly and only in critical situations.
Building a culture of trust reduces the need for constant deadlines.
Autonomy and ownership foster creativity and responsibility in teams.
Continuous feedback and smaller scopes enhance learning and quality.
Innovation is driven by giving teams the freedom to experiment and learn.
Sustainable growth comes from prioritizing quality over meeting arbitrary deadlines.
Eliminating unnecessary deadlines can lead to a more motivated and effective team.
Moving away from rigid timelines can bridge the gap between development and business.
Engineers thrive when they work on improving outcomes rather than just completing tasks.
Share this post