.jpeg)
Organizations that practice agile, but self-impose (or are imposed) deadlines to deliver products or features into market almost always end up delivering a terrible feature, or worse, lead themselves to their long-term demise. This post will explain why deadlines are created, and why they're so bad for the product long-term. I want to be clear here that I'm no agile fanatic myself, but this is a case where some of its principles are deliberately clear.
There is one exception - hardware, so lets focus on software.
How deadlines destroy teams
Let's get straight to why deadlines decimate products and teams.
- Deadlines create undue stress and burn-out on front-line engineering teams to deliver by a certain date or else.
- Deadlines create a lack of control for product managers caught in-between engineering teams unable to deliver, and executives expectations.
- Deadlines deliver crap code from engineering teams rushing to complete a feature, often overlooking important steps.
- Deadlines stifle creativity - as everyone in the organisation focuses on the deadline rather than think creatively on solving the problems at hand.
- Deadlines create tunnel-vision, imposing laser focus on the task at hand, creating a failure for everyone involved with delivery to look beyond at the wider why.
... with little evidence to show they work
I have never seen any company I've worked at deliver anything on the deadline date set, so my personal evidence score is 0%, however, reading what McKinsey say - "on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.". Now I'm not a betting person, but what this clearly demonstrates is deadlines don't mean much and companies end up having to increase costs, or reduce scope, just to meet an arbitrary timeline.
Why are deadlines imposed?
Deadlines are specific dates by when we must deliver our feature into the hands of our customers and the market. There are several reasons why a deadline is imposed, and justifiably so in its own sense. For example:
- Co-ordination with other teams in the organization.
- Expectations set with customers about when their feature is coming.
- Co-ordination and expectations set with a partner organization.
- Reporting to the sharemarket / shareholders about progress.
- Promises made by product executives to others in the business or elsewhere that their org has competency to deliver.
- Projected revenue increase once a feature is launched.
- An attempt to increase engineers productivity.
...and why the reasons are excuses
The reasons listed above are completely justifiable in its own right. Everyone has deadlines for a reason right? Almost all deadlines are imposed or accepted and passed down from senior executives or decision makers within an organisation.
- Other teams such as marketing don't need deadlines either, they can also work alongside you to release their campaigns, etc with you.
- Don't make promises you can't keep. Customers in 2023 understand SaaS - they understand they will get regular updates, just like their iPhone gets updates. Sure they may want a heads up, but continuous, iterative updates always keep you in better shape than promising to deliver x feature by a certain date.
- Partners are tricky, as they may be working towards a certain date with you. the key thing is to set expectations from day one that both of you are in it together and working together for the same common outcome. Remember - outcomes, not output.
- Shareholders are looking at your financials, not whether you delivered something on a specific date.
- That's just executive ego, and nothing in the universe is going to solve this one.
- This just means we need to go as fast as we can go, not that we need to deliver by a specific date.
- This demonstrates a wider cultural problem within the organization if engineers cannot be their best self at work / be the most productive they can be.
What works better?
The answer here is really quite simple. Continuously deliver value through slicing and experimentation. Build small iterative chunks, test it out, see if works, then keep building on it. It's amazing to me how many experienced, senior product people (and their wider exec team) get this so wrong. Don't let your ego or perceived organizational pressure cloud your judgement.
Communicate and collaborate with other parties - other teams and maybe even customers. This is a team effort. Showcase your progress so far, your learnings, your pitfalls and setbacks. Customers sign and re-sign contracts based on the overall value you offer them, they want to be part of your journey, because they have a vested (hint: financial) impact in you building the right stuff.
It also requires product maturity - understand you are product people working on living breathing products that will continuously grow over time - like trees, not lego blocks.
That project management triangle
The sad tragedy at the end of this post is I know that there will never be a day where deadlines are not imposed on the delivery of features. There will be a plethora of reasons (excuses), burnt out engineering teams, failed products, and failed companies that will continue to lie in the wake of deadlines (aptly named I suppose).
It's so fittingly ironic that after a decade of product management across companies big and small, I go full circle back to my university notes, specifically, Information Systems 110 from the ISOM department at the University of Auckland. I still remember the second lecture in the large lecture hall, where Andrew Eberhard showed this image to thousands of freshmen students describing academically the constraints of project management - the project management triangle, developed in the 1950s. I've never seen a model hold more true as the years go by.
