I sent this email to my team earlier in the year to convey that using dates can be an effective tool for your software team. Sharing more broadly here in case others find the framing useful:
Hey all,
Sending this note to provide some clarity for a question that has come up in conversations a number of times recently:
How should we be using release dates effectively as an organization?
Nomenclature
First, I want to level set on some nomenclature. 99% of the time, when we set a target release date for a new product launch (Alpha, Beta, GA, etc.) we’re setting an internal date for the team to rally around. We have the luxury of being in a customer domain where we don’t have many external date commitments.
That said, sometimes there is the need to set an external date. Example of an external date: “We will be releasing Foo service on Jan 1 so that you have a full 6 months to migrate from the existing Bar service. Please plan accordingly.” We should use external dates very sparingly as a Product / Eng organization and only commit to external dates when there is an outsized ROI to do so. If we’re going to commit to an external date, then our Product team has the responsibility to communicate the “why” behind this decision and get buy in the from the Engineering team. I can think of less than five cases where we’ve made external date commitments in my entire tenure here.
Internal Dates can be a powerful tool
Dates can be a very powerful tool when used wisely:
Rallying Point — Dates can be used as a rallying point across multiple teams to ensure you’re all aligning your respective sprints towards a common goal.
Scoping — Once the team has agreed upon a target internal date, they’re useful in helping us force conversations around scope. “Are you sure you want this feature to be included in the Alpha?.. if so, that’s going to push our release out another month”. Conversations like this are healthy and actively encouraged!
Anti-patterns to avoid
I’ve seen some anti-patterns pop up recently that I’d like to make sure we avoid going forward:
Considering Dates to be Immutable — Please note that every member of the Engineering team has the responsibility (and is expected!) to actively push back on a date if it doesn’t seem achievable. We’re in the business of shipping software that delivers value for our customers in a reliable and repeatable way. Work-life balance is a core part of our organization. If you find yourself working 60 hours a week to “hit the date” that is a failure in planning, execution, and communication that we need to adjust.
Cutting Corners — we should not feel pressure to introduce tech debt / cut corners in order to “hit the date”. Sometimes the team may make the conscious / considered choice to do so in order to get customer feedback more quickly, but we should understand that we’re introducing a tech-debt IOU into our stack that we need to make sure we come back and pay later. This IOU dynamic should be the exception, not the rule.
Dates are communicated ‘up the chain’ / we’ll get in trouble if we’re late — it’s true that we do provide visibility into our target release dates to Staff level leaders and other business stakeholders for visibility and planning purposes. That said, we shouldn’t fall into the trap of thinking of these as external dates. We’ll continue to treat them as internal dates and use them as a tool to deliver value for our customers rather than optimizing for “hitting the date”. If we expect that we’re going to slip, let’s communicate early and openly if we expect we’re going to miss our target internal date so our business counterparts can adjust / plan as appropriate.
I hope this is helpful.. Lmk if you have any questions.
..feels like there’s a blog post here :)