Guest Post by Drew Harteveld, VP of Operations, Martha Stewart Omnimedia
Every product build is filled with risks. Some are large, some are small–but all are very real. How you manage that risk can mean the difference between a minor hiccup and a major setback.
Four hours of planning. Six days of development. Three rounds of testing. Two late nights spent wrestling infrastructure. After all of that, you’re finally ready to deploy your sprint branch. The external constraints are drawn tight, the stakeholders are all holding their breath, and the team just wants to check this project off the list and move on to more pressing work. That’s when the other shoe drops, and your carefully orchestrated iteration goes kablooey.
Sweat the Small Stuff
Risk management requires us to rank potential concerns based on likelihood and severity. Since we operate in a world with limited resources, we are forced to focus our mitigation activities on risks that are most likely and have the highest potential for negative impact.
But in observing my own organization over the past several months, I’ve found that as much as 30 percent of the time, the issues that dragged us down weren’t in that high impact/severity quadrant. Instead, they were caused by risks we hadn’t foreseen, as well as some we identified but ranked as low-priority. That’s why we as product developers need to be hyper-critical about every opening we create for risk. Even the components that seem safest have the potential to grind our entire process to a shuddering halt.
This doesn’t mean we shouldn’t build. That’s what we get paid for, after all. (And for many of us, the drive to do so is a calling of sorts.) What it does mean is that we must recognize that product development is a poker game with high table stakes. For every hand we play–even those that appear to be a walk due to our skills and expertise–we are at peril of losing the high ante we brought to the table.
Diligence Above All
To play this game the smart way, we must be extremely diligent when deciding what features to include in our builds. This diligence takes the form of setting a high bar for “Yes”. Before committing to a feature, ask yourself and your team if the functionality in question is:
- absolutely essential in order for us to answer the questions we need to answer to push this piece of business to its next logical step
- exhibiting solid traceability to the business requirements
- robustly supported by quantitative modeling based on how our users are actually interacting with our products today
- specified in its leanest possible form, without a lot of gold plating that will be fun for us to build but not push the core concept forward
- a deployment we can gracefully roll back from if it turns out we were dead wrong
If the answer to any of those questions is“no,” then we need the maturity and intestinal fortitude to push it off. In a business as complex and tightly coupled as ours, even the smallest details have the potential to derail our entire delivery. Last but not least, always be wary of statements like: “…and this one isn’t critical, but it’s a ten-minute job so we’ll toss it in there, as well.”
Final Thoughts
Consider this: Pete Conrad was among the most respected astronauts in U.S. history. Navy test pilot, flew the Gemini, walked on the moon, and repaired the Skylab in orbit. A risk-heavy resume, and Conrad made it look like a walk in the park. In July of 1999, while riding with his wife and some friends, Conrad ran his motorcycle off the shoulder and wiped-out. No major injuries, so Conrad dusted himself off, picked up his bike, and rode on. Six hours later, he was dead of internal bleeding. It wasn’t the huge risks that got him–but the small ones.
Drew Harteveld is VP of Digital Operations at Martha Stewart Living Omnimedia. This is his first post for The Hired Guns.
