Maintaining sanity during launches

This started out as an entry about striking a balance between time to market and producing a quality product for the customer. But as I read through it, I’m really just talking about having a healthy relationship between the business and engineering during project development and launches. So this is basically about minimizing some of the conflicts, and understanding the perceptions and constraints during a release. I won’t pretend to speak from a business background. My POV is from the operational and end-user roles, so if this seems fairly engineering-focused, you’re right. It is.

Btw, my definition of “the business” is anyone in product management, marketing or anyone director-level or higher, including engineering leadership. High-level managers tend to be so far out of the day-to-day that they’re not in a good position to speak for their engineers on project planning or delivery. It’s been a very rare occurrence when I’ve seen a manager who’s more than one or two levels removed from individual contributors actually speak intelligently about how long it’ll take or how difficult it will be to code something. It’s not a slight on them- it’s not where they should be spending their time anyway.

Openness (“we’re all on the same team here”)

It always amazes me when open and honest communication between business and engineering partners doesn’t exist during a launch. The more engineers understand about the business goals for a specific project, the more invested an engineer will typically be in the outcome. I don’t think I’ve ever seen an engineer get worse because they had more information about a project they were working on. Not saying it doesn’t happen- I’ve just never seen it. There are a few questions that seem to spawn the right conversations almost without fail.

  • What are we trying to accomplish? (What is the expected end result for this iteration?)
  • What are the non-negotiable deliverables which must be launched in order to satisfy the business requirements?
  • What is the drop-dead date when this must be launched? What happens if the date slips?
  • How will we know that the launch is successful?

Engineers hate releasing what they feel is an inferior product. Addressing these questions up front and again throughout the process can help alleviate quite a bit of that angst. IMO, giving engineers the background on the drivers behind a project only makes them more able to be a partner rather than just another resource.

Accurate, respected scoping and time lines

We all know that there are unforeseen issues that crop up during projects. It happens. The best you can do is ensure that engineers are setting realistic time frames up front, including testing and operational dependencies. Do you work with a remote development team? Make sure you pad your time line accordingly so you account for delays in communication. Do you need more hardware to accommodate the project? Build it into the plan. Depending on the project, make sure that you account for bugs in the system, software or process. It happens. No one should hide or be ashamed of it. Call these things out in your time line so that everyone understands what’s involved. If the business never hears about these challenges, then how can you expect them to fully grok what it takes to launch their new feature?

The business needs to respect the time frames given by engineering and realize that cutting corners will not only frustrate the people building the product, but will most likely produce an inferior product for the customer. Ditto on ‘scope creep’. Agreeing on a spec and time line and then requesting additional features within the same development cycle will dilute the time and attention that can and should be given to the core product.

I’ve seen iterative development (a la scrum/agile) help with both of the above points when done properly. Engineering should be able to offer something that the business can look at early on in the development cycle so that course corrections can be made prior to the actual launch. Adjustments to time lines and/or requirements can be made more easily when there are more frequent check-ins. Waiting until just before a launch (or, worse yet, once it gets to QA) to review the product leaves very little time for the corrections that invariably surface during any major release.


Everyone needs to be prepared to compromise during a project. Choosing the right concessions to make should be a partnership and a discussion, not a mandate. All participants must be able to adapt to changes in either the requirements or the time line when unexpected issues crop up. Understanding and remembering that everyone involved in the project wants it to go smoothly is a good first step. Discussions around compromises or changes are much easier to have when the communication referenced above happens early and often in the project. Figuring out what the acceptable level of ‘bugginess’ in the product should be is also a good thing to define. Software is never perfect. Everyone involved needs to understand what ‘launch-ready’ means. Setting aside time directly after the launch to fix major (but acceptable-for-launch) bugs goes a long way toward combating engineers’ frustration at launching with those flaws in the product.

One thing that needs to be said here somewhere is that if everyone involved truly does have the customer’s best interests in mind, then that should set the right tone and framework for all of these conversations. If you don’t know your customer, then you can’t make solid, informed decisions about the product in the first place. I get the idea of market research- if that’s the goal of the project, then it should be called out as such- not only internally, but externally as well. I’ll gladly join a ‘beta’ program to test something out. If I’m presented with an inferior product without understanding that it’s still in development, I most likely will never come back to the site.

Trust and butt out

Let the business do what they do best, and let engineers do what they do best. Seriously. I’m not saying that everything should be taken at face value, that there shouldn’t be any contention or pushing here and there to keep everyone honest. Just saying that MBAs aren’t usually coders, and people with CS degrees shouldn’t typically be charged with the long-term vision for growing the business (although I’ve seen a lot of great ideas spawned from the engineering ranks). When an engineer says that coding a new feature will take 40 man-hours, then the business shouldn’t ignore that and promise that the project will launch in two days. And when the business requests a new feature that is supposed to grow the user base by 40%, it’s not the engineers’ call to agree/disagree with that claim or to push back on the validity of launching the product itself. (techincal feasibility aside, of course).

And finally…

Please note that while these are all ‘soft’ points that should probably be rolled into ‘process’, none of this means that a project needs to move more slowly. In fact, addressing this stuff up front should make most launches progress more quickly because you cut out the back-and-forth and a lot of the confusion about what the end goal really is. (I really hate it when people infallibly equate process with moving more slowly. That’s crap.)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s