How can I make it easier for my team and stakeholders to work with me on the marketing launch timeline when engineering releases are sometimes delayed?

My advice is to separate the ship and launch functions. In my experience when they are paired together, there is so much unproductive internal thrash when eng encounters delays and all the downstream teams have to re-adjust their plans. Instead, group new products and features into larger campaigns where if something doesn’t get released on time, you still have a compelling story to tell and your campaign doesn’t get derailed. Set expectations that all features must ship by X date to be included in the campaign.

This also has the benefit of creating more impactful launch moments where you can tell a bigger, richer story about the value you are delivering to customers through a plethora of new offerings.

I think it's safe to say that all product releases come with some sort of delay or scope change, it's to be expected. But, it can oftentimes impact the morale of the team if there are repetitive delays.

The biggest thing you can do is be transparent from the beginning. Oftentimes, if you're working closely with your product teams, you can get a sense if things may slip and dates may change. When you get that feeling, it's important to have a conversation with your PMs about it so that you can relay information to your team as soon as possible.

I have three tips...

First, turn delays into a positive. Not always possible, but when you can, it's a big help. For instance, if a launch slips a month or quarter, position it to the group as an opportunity to do that extra thing on the website that could help increase conversion or write those extra blog posts to be used in social that could drive better awareness. Again, it's not always possible, especially if you work for a larger business where teams workloads are planned out, but it can help. 

Second, always come with a new plan. This goes hand in hand with the above point, but if you hear from your PMs that a launch is delayed, make sure to go to your stakeholders with new dates and timelines - echoing that they have more time to build out these deliverables.

Third, drive home the point that building software or launching new products is really, really hard. Oftentimes, development teams hit unforeseen complications that delay things - it's to be expected. From the beginning, set this tone with the team and let them know that there may be changes in scope and that it's important to be flexible, because at the end of the day whatever you're launching is going to have a great impact on your business or customers. 

I've never worked anywhere where releases don't get delayed - delays happen. The best you can do is to stay in as close communication with your key stakeholders as possible - informing them of updates in real-time. You won't lose trust with your team if you're open and honest: put a stake in the ground and establish a launch date if there isn't one, so that everyone can start planning their respective workstreams and you can ensure a successful launch. But also clearly communicate that there's a chance the date may slip. You can hold a launch planning session on a regular cadence (every week, leading up to a critical launch) where you bring stakeholders together to discuss latest timelines and workstream updates.

EVERY company I've ever worked for, the engineering releases were mostly... not on time. And before you think that's a dig, let's levelset.

Product development is hard. You are bringing an idea to life and testing it in the wild. You make decisions that work or don't, and then have to clean up later. You get pulled by customers to do things you didn't originally scope, and sometimes have to pivot (a lot). Product development done right is iterative, messy, and non-linear. The best products are not built in clean sets of two-week sprints. In other words, releases are a "guess-timate" at best.

Knowing this, you have to balance doing right by stakeholders with the mess that is product development. Some learnings from my experience:

• Align with the head of product on the most important product updates and what timeline makes the most sense to communicate broadly—and be general. You'll thank yourself x100 that you said "By end of quarter" and not "June 15th."
• Become milestone (versus timeline-oriented) for GTM updates. Let the teams know why you are starting work on something even though the timeline might move (e.g. "We'll kick off wiring up the onboarding emails once the product team finishes the last billing update this week or early next" versus "we'll kick off onboarding emails May 2nd"). It helps channel owners understand that you are working off a product plan versus setting arbitrary dates.
• Create a forcing function. If your PM team is open to it, there is NOTHING stopping you from launching things right after they are code complete. Giving marketing teams the buffer that something is live and exists while wiring up flows, experiences, ads, webpages, etc is SO much smoother. OR, you can work with your head of product to do a "Seasonal Release" that has a locked date your engineers can work toward. Doing so will also help you get more predictability on timeline since the date is immutable (or at least feels that way).

Engineering timelines change for a variety of reasons. It's just the nature of the work. To help manage the expectations and emotions of others working on the marketing timeline, I take this approach: 

Communicate early, openly, and as often as possible. That way, folks don't feel out of the loop or in the dark, and they know you have respect for their time and effort. 

Don't overcommit to to timelines. I approach and communicate them with the caveat that there is always the possibility for delay. 

Focus on the customer. When engineering is delayed, it's likely that the team ran into unforeseen difficulties building the feature, challenging bug fixes, or there was a shift in prioritization. All of these things have the potential to impact the customer experience negatively. In communicating with launch stakeholders, I always circle back to being customer-first and delivering the best possible experience. Being customer-first means just that. We take on the domino effect delays can cause for the sake of their experience. 

Empathize with their disappointment and move forward. We are all humans and humans have emotions. Acknowledge that folks may be upset, then work with them to talk through next steps. That may be holding off on a deliverable and prioritizing something else in the meantime. Or, moving forward as planned and having everything tee'd up when the feature is ready.