Fake deadlines
Deadlines are not inherently bad. They are very needed and inevitable for a lot of things. I don't want to make this post become a rant about deadlines. I want to talk about the "fake deadlines" we put for the wrong reason and that are not helping our teams and neither delivering value to our users.
Delivering product increments is not that hard, delivering the "right" product increments is.
Some time ago I read an interesting post that described fake deadlines as: "...when missing the deadline has no actual consequence to the business. The deadline exists only so that we pretend it’s real and demonstrate the same stress and urgency that we’d use for a real deadline.". I only partially agree with this definition, but I fully agree with the statement that there is a strong downside to using this tactic.
I would argue that often deadlines are set to create "contracts" between the product teams and the different stakeholders. These "contracts" create a false sense of control, often followed up with "status meetings" or "steering committees" to check up on this "contract fulfillment". This is highly detrimental to delivering real value for the users and by extension to the company.
It perverts and shifts the focus where it should not be, we talk about hitting deadlines instead of understanding the impact of what and why we are delivering.
Fake deadlines keep pushing to focus on outputs instead of focusing on outcomes.
In my experience, for having a healthy relationship with the different business stakeholders there are two main things needed:
- Strong alignment
- Trust
I believe, if those two ingredients are there we have a very good foundation to work on.
Strong alignment
When there is alignment and a deep understanding of the desired outcomes, prioritization is easier, and making the right decisions on what to focus on also becomes more clear.
Having strong alignment is not so easy, especially when the company has a big product portfolio often grown organically from different projects and without orchestration.
The best way of achieving strong alignment is by creating a good strategic framework. As explained in the wonderful Melissa Perri's book "Escaping the build trap" the strategic framework is how the company realizes the vision through product and service development in the market. "Aligns the company's strategy and vision with the products that are developed by the teams".
The strategic framework is how the company realizes the vision through product and service development in the market
There are also different approaches and frameworks for having a correct strategy deployment across the organization, also as explained in Melissa's book in most product organization there should be four major levels:
| | | | |--------|--------|--------| | Vision | What do we want to be in 5-10 years?. Value for customers, position in the market, what business looks like. | CEO/Senior leadership | | Strategic Intent | What business challenges are standing in the way of reaching the vision | Senior leadership / Business leads | | Product initiative | What problems can we address to tackle the challenge from a product perspective? | Product leadership team | | Options | What are the different ways I can address those problems to reach my goals? | Product teams |
Maintaining a continuous flow of communication up, down, and across the organization is also key to maintain alignment.
Trust
Having a good strategy deployed in our organization is not a silver bullet that will make everyone "comfortable" and provide the "sense of control" that often is expected in organizations. This is especially true for organizations that are transforming from project-led to product-led.
There will be many uncertainties, things that the teams do not know yet, issues will arise along the way... There needs to be trust among the different teams in the organization. Trust is a two-way street and it builds up over time.
Trusting the teams while providing them a strategic framework where they can decide how to address the user needs to reach the company goals is paramount to build ownership.
Many companies often talk about having "autonomous teams", a little bit like having "agile" sometimes become more like a buzzword than a reality. Is it autonomy when we tell our product teams what they need to build and just expect an estimated deadline on the delivery?.
Allowing space for the teams to decide what to build (they own the Why!) is paramount for creating ownership on the team, ownership drives execution and maximizes value delivery for users.
That requires trust.
I believe then we can have a really virtuous circle:
Trust → Autonomy → Ownership → Execution → Value
As uncle Ben said, a great power comes with a great responsibility... Trust needs to be rewarded with full transparency and execution. Otherwise, the company will soon fall back to the habit of creating "fake deadlines" to regain the feeling of being in control and "steering" the execution in the right direction. And we would be back to square 1.
Interesting related articles
- Three reasons to stop talking about time and deadlines in Agile environments
- Abandoning fake deadlines
- How Product Teams Can Build Trust with Internal Teams
Photo credit Artem Maltsev